Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

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

by Nemp (Pilgrim)
on Sep 02, 2002 at 13:58 UTC ( [id://194578]=perlquestion: print w/replies, xml ) Need Help??

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

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

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...

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:

    1. Someone might be updating the file, and that someone is doing an exclusive lock himself.
    2. 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.
      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
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 :-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://194578]
Approved by tadman
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2024-03-29 07:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found