>> I agree that it's fairly bad. But, if you make sure that you're the
>> only client operating on a certain file which has never existed before,
>> the results aren't so bad (if the NFS-client and server are a good quality
>> implementation).
>Why should you want that?
In order to implement a locking scheme, or a maildir type mail delivery
system, that works across NFS.
>IMHO, relying on any such thing is evil. People will surely use your code
>in environments where that assumption doesn't hold; after all, it works (almost)
>flawlessly regardless, right?
>The "almost" is the problem.
It's not really a problem. The assumption is *not* a requirement to make
the code work correctly. If the assumption does not hold, two things
can happen:
- The code will work regardlessly, because it anticipates some kind of
deviation from the standard.
- The code will report a problem, and will refuse to continue.
>Read maildir(5), a manual page from the qmail system. It describes a reliable
>mail delivery system which works over NFS, even if multiple mail servers
>write to the same mail spool.
It makes use of the same assumptions I made to implement the
NFS-resistent-locking scheme. It wouldn't surprise me if Bernstein
took a good look at the locking scheme before creating the maildir
implementation.
>much yet, unfortunately. However, IMHO it's a much better idea to create a
>patch for elm which supports maildir than to invent yet another limited-use
>locking scheme.
This locking scheme predates the maildir implementation by more than six
years. So we're not inventing "yet another" locking scheme.
--
Sincerely, srb@cuci.nl
Stephen R. van den Berg (AKA BuGless).
"I don't like this word bomb. It is not a bomb, it is a device,
which explodes." French Ambassador about the atomic tests.