File Locking with fcntl on Darwin Mac OSX

Hello

I have a Perl script that works on non-darwin Mac OS X environments and I think I have narrowed down the issue to a file locking problem.

In other linux environments, the flock struct is defined differently. I have adjusted this via the reference for Mac OS X fcntl(2) man page. The struct is defined as:

struct flock {
                 off_t       l_start;    /* starting offset */
                 off_t       l_len;      /* len = 0 means until end of file */
                 pid_t       l_pid;      /* lock owner */
                 short       l_type;     /* lock type: read/write, etc. */
                 short       l_whence;   /* type of l_start */
             };

I am using the flock as the following:

my $msg = fcntl( $LOCKF, F_SETLK, pack("lliss",0,0,0,F_WRLCK,0) ) or die "Something wrong: $!";

The adjustment works on a separate test script that I extracted parts of the script out for testing. However when I deploy it to the real script, it doesnt work anymore. I then did a trial-error sequence and found that after certain 'additions' to the code, anything I add, such as a simple print "hello" statement, would result in the fcntl line not working. (The error outputted is Invalid Argument supplied).

Is it because the offset, len, l_whence are not defined correctly?

Please help. Thanks for your help.

You shouldn't be using ioctl in perl. If your structure and C's disagree even slightly, then weird things can happen. If your structure and perl's completely agree, weird things can still happen. There may be memory alignment considerations and the like which rearrange or misalign the members from the arrangement you expected, only the C compiler's judgement should be trusted on that.

I seem to remember 'struct flock''s arrangement does seem to be different in OSX than in Linux, too. Something about one of the types involved not actually being an integer anymore.

Fortunately, perl has a built-in flock function so you don't need to call ioctl yourself. It's not even a module, it comes with standard perl.

$ perldoc -f flock
       flock FILEHANDLE,OPERATION
               Calls flock(2), or an emulation of it, on FILEHANDLE.  Returns
               true for success, false on failure.  Produces a fatal error if
               used on a machine that doesn't implement flock(2), fcntl(2)
               locking, or lockf(3).  "flock" is Perl's portable file locking
               interface, although it locks only entire files, not records.

               Two potentially non-obvious but traditional "flock" semantics
               are that it waits indefinitely until the lock is granted, and
               that its locks merely advisory.  Such discretionary locks are
               more flexible, but offer fewer guarantees.  This means that
               programs that do not also use "flock" may modify files locked
               with "flock".  See perlport, your port's specific documenta-
               tion, or your system-specific local manpages for details.  It's
               best to assume traditional behavior if you're writing portable
               programs.  (But if you're not, you should as always feel per-
               fectly free to write for your own system's idiosyncrasies
               (sometimes called "features").  Slavish adherence to portabil-
               ity concerns shouldn't get in the way of your getting your job
               done.)

               OPERATION is one of LOCK_SH, LOCK_EX, or LOCK_UN, possibly com-
               bined with LOCK_NB.  These constants are traditionally valued
               1, 2, 8 and 4, but you can use the symbolic names if you import
               them from the Fcntl module, either individually, or as a group
               using the ':flock' tag.  LOCK_SH requests a shared lock,
               LOCK_EX requests an exclusive lock, and LOCK_UN releases a pre-
               viously requested lock.  If LOCK_NB is bitwise-or'ed with
               LOCK_SH or LOCK_EX then "flock" will return immediately rather
               than blocking waiting for the lock (check the return status to
               see if you got it).

               To avoid the possibility of miscoordination, Perl now flushes
               FILEHANDLE before locking or unlocking it.

               Note that the emulation built with lockf(3) doesn't provide
               shared locks, and it requires that FILEHANDLE be open with
               write intent.  These are the semantics that lockf(3) imple-
               ments.  Most if not all systems implement lockf(3) in terms of
               fcntl(2) locking, though, so the differing semantics shouldn't
               bite too many people.

...

do you mean not use fcntl? you typed ioctl...?

fcntl, ioctl, same difference -- they're both raw system calls which need C data structures. You shouldn't be using them in perl, especially for programs you want to be portable. This might fail in different CPU architectures of the same Linux kernel, let alone a foreign OS.

perl's flock function exists because they're not the same everywhere.

thanks for your help. its interesting that i was able to get it to partially work but i guess it makes sense that the behavior is unpredictable at best. i never had an issue where adding debug print statements can break a script.