The necessity of flock-ing files that are only to be read.

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

Hi monks,

I have a file on my webserver which needs to be read from to help produce some of the pages. I've been looking through the documentation for flock and some other previous posts here, such as here and the tutorial on file locking by turnstep, and I've come up with a few questions...

FYI: I'm not sure if this will change any answers or not but I have a sneaking suspicion it could; My host uses IIS on Windows2000 and I already know that flock() is supported.

First of all I read that appending to a file simultaneously without a lock just causes the data written to the file in an inter-mixed fashion. As I only plan to read the file - does this indicate I do not need to lock it? It is a static file and will theoretically not be changed ever. Should I use shared locks or are these rendered unnecessary by the fact I never plan to write or append to the file?

Thanks,
Neil

Comment on The necessity of flock-ing files that are only to be read.

Replies are listed 'Best First'.
Re: The necessity of flock-ing files that are only to be read. by davorg (Chancellor) on Sep 02, 2002 at 14:02 UTC
Shared locks are there to protect files from being updated whilst you read them. A shared lock is a signal to the operating system which means "don't let any other process take an exclusive lock on this file as it might change the data I'm reading in mid-read". A file can have any number of shared (read) locks at any given time. But the operating system will only give an exclusive (write) lock if there are no other locks (of any type) currently on the file. -- <http://www.dave.org.uk> "The first rule of Perl club is you do not talk about Perl club." -- Chip Salzenberg	[reply]
Re: The necessity of flock-ing files that are only to be read. by thpfft (Chaplain) on Sep 02, 2002 at 14:11 UTC
If the file isn't ever going to change, you don't need to lock it. It might be a good idea to change the permissions on the file to make sure, if w2k lets you do that. It will at least give someone pause when they come to update the file. On the other hand, there's no strong reason not to read-lock the file, and it is a good habit to adopt. You never know when it might be updated by some other process written by some other person...	[reply]
Re: The necessity of flock-ing files that are only to be read. by Joost (Canon) on Sep 02, 2002 at 14:21 UTC
As I only plan to read the file - does this indicate I do not need to lock it? It is a static file and will theoretically not be changed ever. Should I use shared locks or are these rendered unnecessary by the fact I never plan to write or append to the file? If your scripts (or any other programs) don't modify the files you don't need to lock them. The only reason to (shared-)lock files you are reading is when both: Someone might be updating the file, and that someone is doing an exclusive lock himself. Things go wrong when the file you are reading is malformed, for any definition of 'wrong' and 'malformed'. For instance: say I have a small script which shows the last X lines of a log-file. Now, I only use the script for debugging purposes, so even though the log-file might be updated, I do not need to lock the file because it doesn't matter if the read goes wrong sometimes (in this case the most likely 'misread' will be an incomplete line at the end). On the other hand, if I use a file for passing data from one program to the other, I really need the data to be consistant, so I should use locking on the read and the writing side. Hope this clears it up a bit ;-) `-- Joost downtime n. The period during which a system is error-free and immune from user input.` [download]	[reply] [d/l]
Re: Re: The necessity of flock-ing files that are only to be read. by Nemp (Pilgrim) on Sep 02, 2002 at 15:57 UTC
Thanks for all the replies especially this one! This answer has really helped clear things up for me! I'm implementing shared locks on my file now - just to get in the habit and in case I ever decide I need to update that file in the future. I appreciate the help! Neil	[reply]
Re: The necessity of flock-ing files that are only to be read. by adrianh (Chancellor) on Sep 04, 2002 at 13:06 UTC
Just one quick comment. While it is implicit in Joost's comment it's worth saying that flock() based locks are co-operative - they're only effective for those programs that choose to use flock(). While having shared locks is a good thing if all the processes accessing the file are using flock() based locking, it will be of no use at all if there is some other process that just writes to the file without getting an exclusive lock first. Just thought it was worth making explicit :-)	[reply]