Flock Flock Flock

[Brett_Tabke]

Is there a definative resource or tutorial on the whole issue of Flock somewhere? I say that cautiously since there is so much noise about it, that finding "the guide" is difficult.

Obviously, I use flock daily. I feel like I only know half the issues involved. It's so *nix centric. Years of using file locking on other file systems has muddled my usage.

Basically, I only flock on writes. Then I only flock if the entire file is rewritten. If it is just an append, I don't go for an exclusive lock.

[sugarkane]

I don't know of a definitive guide, but my rule of thumb is 'If a file is to be written to, by any script at all, at any time, then every access should be flocked exclusively whether reading or writing'

That's ultra-cautious, but I've had files nuked before now where I couldn't for the life of me work out where the problem was. Since I adopted that rule of thumb the problems have gone away.

In a multi-user system, there are (for me) just too many possible sequences of events to be 100% confident that I don't need to flock a file, so I do it as a matter of course :)

Is there a downside to doing this? Is flock particularly system intensive?

[bird]

I don't have the ultimate guide either (besides the man pages...), just some basic rules derived from common sense.

You can't do any harm to the file by reading without locking. The worst thing that will happen if another process writes at the same time is that you read garbage, ie. parts of the old contents, and parts of the new, and display strange results in the generated HTML. Of course, if you first read, with the intention to modify the same data after that, then you should encapsulate both the read and the write in an lock together, so that no other process can fumble in between.

An append is really no different to a normal write, except for where in the file you start writing. If two processes start appending to the same file at the same time, then their writes can interact in strange ways. If the second process starts writing after the first one has done half of its work, then their data may become mixed up (unless, of course, you know for sure that a single write() system call with your kernel/file system is atomic in all circumstances).

In short, if you're writing to a file, or if you plan to write modifications to what you're reading, use a lock. Any lock.

*nix centric? Hmmm... have you had a look at fcntl() lately? ;)
If you're worried about performance/concurrent accesses, then fcntl offers the possibility to lock only parts of your file, and you can lock files across NFS, while flock() only works on local file systems. Fcntl() is available in the Python library, so it's probably accessible from Perl as well (which I assume you're using).

[volatilegx]

here's my basic guide to flock():

I write a lot of scripts that must be cross-platform compatible (a nightmare). What I like to do is detect the presence of a Windows operating system and disable flock() if present. I've found flock() often fails on a MS system. If anybody has a way to flock on a MS system, please stickymail me.

Anyhoo, here's an example of my syntax for flock():

$winserver = 1 if $ENV{'SERVER_SOFTWARE'} =~ /Win/i;
open(HANDLE, "<foo.txt") or die("could not open foo.txt:$!");
flock (HANDLE, 2) unless($winserver);
@filecontents = <HANDLE>;
flock (HANDLE, 8) unless($winserver);
close (HANDLE);

Basically the same syntax if writing to a file.