in reply to Order of flock and open

While all of the other posters are correct, there is one thing that I'd like to mention. Locks are advisory in much the same way that stoplights are advisory. Nothing keeps someone from ignoring a stoplight and plowing in to an intersection. Similarly, if you have a process that pays no heed to locks, you'll be in for a nasty surprise if you were relying on the locks to protect your data.

thor

Replies are listed 'Best First'.
Re: Re: Order of flock and open
by John M. Dlugosz (Monsignor) on Apr 30, 2003 at 21:47 UTC
    Some OS's (such as Windows) have file locking at the OS level. Those are not advisory, but are enforced for all handles, period.

    For example, under Win32 API the LockFile function will prevent any other process from accessing the region of the file, period. The other process doesn't have to call LockFile and stop itself; just using a handle open to that file that would read/write the restricted region will become an error.

[reply]
Re^2: Order of flock and open (mandatory locking)
by Aristotle (Chancellor) on May 02, 2003 at 00:48 UTC
    Note that on Linux does offer kernel enforced, mandatory locking. See /usr/src/linux/Documentation/mandatory.txt for details.

    Makeshifts last the longest.

[reply]
      I'd like to ask: are the two manditory file locking methods mentioned above called by the perl flock call? If so, that'd be good for portable code. If not, you've got a big cludge in which you have to examine the operating system to determine what to use.

      thor

[reply]
        I did say Linux supports .. :) Depending on what you're trying to do, it might be helpful to know. If you are trying to write portable code, then it certainly isn't.

        Makeshifts last the longest.

[reply]

In Section Seekers of Perl Wisdom