in reply to Re^2: locking over the network
in thread locking over the network

The man page is quite clear what it does. Did you read it? You only have to read the first paragraph.

- tye        

  • Comment on Re^3: locking over the network (NFSLock)

Replies are listed 'Best First'.
Re^4: locking over the network (NFSLock)
by rovf (Priest) on Feb 02, 2011 at 10:27 UTC
    The man page is quite clear what it does. Did you read it? You only have to read the first paragraph.
    Yes, I *did* read it, and it says that this class applies only to locking over NFS (which is not a big surprise, considering the name of the class). That's why I said this class might be nice, but doesn't help me much, because it would require that the file to be locked is accessed via NFS. Or did I misunderstand something in the documentation?

    -- 
    Ronald Fischer <ynnor@mm.st>

      Then I guess you need more practice reading. I don't see the word "only" in the description and what is clearly described in the first paragraph is precisely the approach offered elsewhere in this thread as a generic approach known to work over NFS but not "only NFS": "creating a random local file, hard linking a common file to the local file, and then checking the nlink status".

      The module Name is even documented as "File::NFSLock - perl module to do NFS (or not) locking" where, just to be clear, "or not" indicates that NFS is not required.

      - tye        

        Maybe I indeed need more practice reading, or at least improve my English. The first paragraph says:

        Program based of concept of hard linking of files being atomic across NFS. This concept was mentioned in Mail::Box::Locker (which was originally presented in Mail::Folder::Maildir). Some routine flow is taken from there -- particularly the idea of creating a random local file, hard linking a common file to the local file, and then checking the nlink status. Some ideologies were not complete (uncache mechanism, shared locking) and some coding was even incorrect (wrong stat index). File::NFSLock was written to be light, generic, and fast.

        I can read here: "Program based of concept ... being atomic across NFS". I have understood this as being a class which is used to do locking on NFS. Please explain where I misinterpreted this text.

        Also, I am curious to know in what respect using NFSLock is better than my original solution. For example, is the code which I posted unreliable? If so, this would certainly be an argument to try NFSLock.
        -- 
        Ronald Fischer <ynnor@mm.st>