Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

sysopen function call

by rpike (Scribe)
on Sep 08, 2010 at 13:58 UTC ( #859320=perlquestion: print w/replies, xml ) Need Help??
rpike has asked for the wisdom of the Perl Monks concerning the following question:

I have a call to the sysopen function with a legimate directory path but the filename does not yet exist. The full call is :
sysopen (LOGFILE, $fullLogFile, O_RDWR | O_CREAT) or die "Cannot open +".$fullLogFile." for writing. ".$!;
$! - is set to No such file or directory The directory is correct and I checked the permissions on the directory for read, write, create,..... and everything looks good. Is there something else I can try? Another system variable to print? Etc..,? Any help would be appreciated. Thanks.

Replies are listed 'Best First'.
Re: sysopen function call
by Corion (Pope) on Sep 08, 2010 at 14:08 UTC

    Maybe $fullLogFile contains whitespace? I always use delimiters around filenames like this:

    sysopen(LOGFILE, $fullLogFile, O_RDWR | O_CREAT) or die "Cannot open '$fullLogFile' for writing: $!";

    Also, is there any reason you're using sysopen instead of plain open? Also, you should better use lexical filehandles instead of global filehandles:

    open(my $logfile, '+>', $fullLogFile) or die "Cannot open '$fullLogFile' for writing: $!";
      No white space. I checked to make sure of that from command line as opposed to running it as a CGI app (what it's intended to do). If you have a way of accomplishing what I need to do using the open function I'm all ears but I've already posted what I wanted to do prior to this and open doesn't seem to cut the cake. I need to open a file and have a lock on it, read in contents, modify those contents, have those contents written back to the file (overwrite everything in the file with the new stuff), and then release the lock. open didn't work for me.

        If it is running as a CGI app, but not doing what it should, then it is a permission problem between the user your web server runs your application as and the user you use to test from the command line. Maybe your system is using SELinux or something else that interferes, or your webserver is running in a chroot jail.

        open should work for you in your use case, but you don't show any code so it's hard to tell where it fails to do so for you.

Re: sysopen function call
by BrowserUk (Pope) on Sep 08, 2010 at 14:05 UTC

    What happens if you try a standard open instead:

    open (LOGFILE, '>', $fullLogFile ) or die ...;
      Been down that road. I need to read and write to the same file handle. I need to read a file in, modify content, and then write back to the file. After trying open I had feedback I couldn't accomplish it using it because +> was messed up (confirmed that after attempting it as well). Right now I'm trying to get a (should be) simple case of sysopen working but to no avail.
        because +> was messed up

        I strongly suspect that if you posted the complete script, that the reason for your failure(s) would become clear.

        In particular, I suspect that you are attempting to reopen and overwrite an existing file, to which you already hold an open filehandle. If that is the case, and you are running on Windows, the OS won't let you do that.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: sysopen function call
by rpike (Scribe) on Sep 08, 2010 at 14:33 UTC
    Let's break it down to basics for now. Why would a simple sysopen fail on a directory known to exist (i.e. successful use of open confirms the directory exists)? I use a filename that exists and one that doesn't and both fail the same way. I checked the IUSR_XXXX permissions on the directory and also the current system user and both have suffice permissions. Is there another approach to determine why the sysopen is failing? Thankd again.

      I would test all the directories above the directory in question, and I would also inspect $^E, as you seem to be on Windows, and potentially the event log, to see whether there are other access restrictions. Also, I would look at the ACLs for whatever users are trying to access the directories.

Re: sysopen function call
by rpike (Scribe) on Sep 08, 2010 at 18:23 UTC
    Mr_Mischief, sorry I didn't see your post there from before. Thanks a bunch. It worked great. I had Fcntl include there for flock only. Thanks again.
Re: sysopen function call
by rpike (Scribe) on Sep 08, 2010 at 15:50 UTC
    $^E - yields "The system cannot find the file specified"

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://859320]
Approved by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (3)
As of 2018-07-21 18:05 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (449 votes). Check out past polls.