| [reply] [d/l] |
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.
| [reply] |
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>
| [reply] [d/l] |