5.8, locking with IO::File and Fcntl

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

The goal was to read from a mailbox /var/spool/mail/foobar and write the content to someplace else, then truncate it. Logically, I need prevent the MTA from writing; sendmail uses no extraordinary locking according to the Flying Dog book.

Following is a modification of the code from perlopentut which I assumed to be safe. A coworker informed me we got data corruption, at "someplace else" a partial mail was written. The logfiles reveal nothing unusual.

use Fcntl qw(:DEFAULT :flock);
use IO::File;

# [...]

my $mbox = new IO::File $cMailBoxFile, O_RDWR or logthis("could not op
+en <$cMailBoxFile> for read/write: $!";
flock $mbox, LOCK_EX;
logthis("opened and locked <$cMailBoxFile>");
[download]

Does this create a race condition or do I have to look somewhere else for a possible explanation? Does IO::File, when used in this manner, use sysopen internally or not?

Comment on 5.8, locking with IO::File and Fcntl Download Code

Replies are listed 'Best First'.
Re: 5.8, locking with IO::File and Fcntl by jfroebe (Parson) on Mar 09, 2005 at 15:01 UTC
Hi, Well, locking a file with flock() doesn't mean that a lock is actually created at the os level. flock(): On many platforms (including most versions or clones of Unix), locks established by flock() are merely advisory. Such discretionary locks are more flexible, but offer fewer guarantees. This means that files locked with flock() may be modified by programs that do not also use flock(). Windows NT and OS/2 are among the platforms which enforce mandatory locking. So, what you're seeing with the risk of corruption is really documented unfortunately. Take a look at the File Locking Tutorial which will give you a solid base of how the locking is done Also, take a look at the MTA program documentation. sendmail's locking scheme: it does recognize its own locking system, which consists of a mboxname.lock file in the same directory as the mbox. -- ishamael (RE: File Locking) update: Come to think of it, using a progname.lock locking mechanism on unix/linux is very common. Depending on the program you are interacting with (i.e. sendmail), you might be able to get away with flock, a .lock file or similar. You will have to research the program to determine if when the .lock file is created, does the program automatically assume that it can write to the file regardless if the program itself did not create the .lock file? Hope this helps Jason L. Froebe Team Sybase member No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1	[reply]

Replies are listed 'Best First'.

Re: 5.8, locking with IO::File and Fcntl
by jfroebe (Parson) on Mar 09, 2005 at 15:01 UTC

Hi,

Well, locking a file with flock() doesn't mean that a lock is actually created at the os level.

flock():
On many platforms (including most versions or clones of Unix), locks established by flock() are merely advisory. Such discretionary locks are more flexible, but offer fewer guarantees. This means that files locked with flock() may be modified by programs that do not also use flock(). Windows NT and OS/2 are among the platforms which enforce mandatory locking.

So, what you're seeing with the risk of corruption is really documented unfortunately.

Take a look at the File Locking Tutorial which will give you a solid base of how the locking is done

Also, take a look at the MTA program documentation. sendmail's locking scheme:
it does recognize its own locking system, which consists of a mboxname.lock file in the same directory as the mbox. -- ishamael (RE: File Locking)

update: Come to think of it, using a progname.lock locking mechanism on unix/linux is very common. Depending on the program you are interacting with (i.e. sendmail), you might be able to get away with flock, a .lock file or similar. You will have to research the program to determine if when the .lock file is created, does the program automatically assume that it can write to the file regardless if the program itself did not create the .lock file?

Hope this helps

Jason L. Froebe

Team Sybase member

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

[reply]