Re: Order of flock and open

Other posters are mostly correct: Most of the time, you don't need to worry about the fact that there's a delay between the open() and flock() calls. But there are some cases you should be aware of which require more careful consideration.

One issue is if you're opening a file for something other than reading. If you open a file for append, you should seek() to the end of the file after you acquire the lock, to make sure no one else appended to the file after you opened it.

open my $FH, ">>foo" or die "can't open";
flock $FH, LOCK_EX or die "no lock";
seek ($FH, 0, 2);
[download]

If you're opening a file for destructive write, you have a bigger problem. Opening destroys the file, but you can't lock the file until you open it. One solution to this is to lock a different file, as someone else described. Another solution is to open the file twice: open it once for reading, lock it, and then open it for writing once you know you have the lock. As long as you keep the first filehandle open, you'll keep the lock.

open my $LOCK, "<foo" or die "can't open for locking";
flock $LOCK, LOCK_EX or die "Can't lock";
open my $FH, ">foo" or die "can't open for writing";
print $FH "I own this file\n";
close $FH;
close $LOCK;
[download]

Finally, is the situation you describe, where you want to lock a file, rebuild it in a temporary file, and then copy the tempfile over the real file. The issue here is, with most filesystems, when you use rename() or `mv` to replace the real file with the newly built tempfile, you lose your lock on the file. If this is okay (you're done with the file when you copy it over) then it's probably not a problem. But if you wanted to perform any other operations on the file while it's still locked, you probably need to use the "lock a different file" technique.

Alan

Comment on Re: Order of flock and open Select or Download Code

Replies are listed 'Best First'.
•Re: Re: Order of flock and open by merlyn (Sage) on Apr 30, 2003 at 20:08 UTC
If you're opening a file for destructive write, you have a bigger problem. Opening destroys the file, but you can't lock the file until you open it. One solution to this is to lock a different file, as someone else described. Another solution is to open the file twice: open it once for reading, lock it, and then open it for writing once you know you have the lock. As long as you keep the first filehandle open, you'll keep the lock. You keep the lock on the now dead file, but you have a new file that exists but might not yet be fully written. And someone can come along and flock that! Now there are two flocks active. Repeat ad-nauseum, and you get an infinite number of flocks. So, no, that's not the way to do it. Others have posted the proper way. Just wanted to point out that yours is flawed, so erase that part of your brain please. {grin} -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re: •Re: Re: Order of flock and open by ferrency (Deacon) on Apr 30, 2003 at 20:20 UTC
My experiences are probably platform-dependant on FreeBSD. However, those experiences offer empirical evidence that on my preferred platform, opening the file for write a second time opens the same file, not a new file, and subsequent lock attempts on the write filehandle fail. Example: `% perl -MFcntl -e 'open my $f, "<foofile"; flock $f, LOCK_EX; open my +$g, ">foofile"; flock $g, LOCK_EX\|LOCK_NB or die "No lock\n";' + No lock %` [download] In summary: please don't follow my original advice. Merlyn is probably right in the general case, and will probably even find a good explanation as to why I've fooled myself into believing what I do. I'll add a caveat to the particular portion of my brain which holds this information, but I'm unlikely to erase it completely :) Alan	[reply] [d/l]


go ahead... be a heretic
	PerlMonks