A new and very robust method for doing file locking over NFS?

[Douglas Alan]

Charlie Reiman <rando-15696825.5.reiman at xoxy.net> writes:

> I like this idea a lot but it has one drawback. In the traditional
> lockfile approach, you can have multiple readers even if someone is
> writing. Now that you rename the file, eveytime someone is writing the
> filename is a moving target. Depending on how you intend to use the
> file, this might make your solution a no-go from the get-go.

Yes, that is an issue to consider.  In the application I am
considering this for, it is adequate for the locks to be completely
exclusive.

If one wanted to use my approach for non-exclusive locks, I think that
other processes could glob for "filename.locked.*.*", or the locking
process could leave a symbolic link behind.  If a process wants to
read a file and it isn't there, it would wait in a sleep loop for
either "filename" or "filename.locked.*.*" to appear (or for the
symbolic link to appear, depending on which method we chose).  If
neither appears after some amount of time, then the process would
conclude that the file has gone missing and generate an error.

It is possible, although unlikely, that if many processes were locking
and unlocking the file, that one of the processes might see neither
"filename" nor "filename.locked.*.*" every time it looks for them,
even after many attempts, and even though the file is really there.
In that case we would get a spurious "file missing error", but this
would not result in any corrupted data, and if we make the locking
processes persistent and patient enough, this will probably never
occur in our lifetimes.

> FWIW, I've never had any problems with NFS for traditional lock
> files. NFS works pretty hard to get messages where they need to
> be. 

This is somewhat encouraging to hear.  Does your positive experience
extend to Linux NFS servers and clients?

> If I were that deeply concerned or running across an unreliable
> network, I'd probably write my own lock daemon and run it over TCP.

That's certainly another reasonable approach.  I'd prefer not to have
a centralized daemon, however, unless absolutely necessary, because it
makes the software more difficult to install and administer.

|>oug