On Fri, 10 Sep 1999, Raul Miller wrote:
> Can we get liblockfile's program an routines to reliably *fail* when
> it's locking an nfs file?
Yes. Kernel 2.2.* on the client machine caches the file contents and
so doesn't note when the file was changed on the server. Without
fcntl() locking (liblockfile uses dotlock only at the moment) the
cache is not flushed, so the client may overwrite the file on the
server without noting that it was changed on the server in the
meantime.
> If so, perhaps we can recommend Maildir/ for people who need to put
> mail on an nfs partition.
There are some disadvantages with this proposal:
- Not every mail reader supports maildir
- maildir uses more space on the filesystem than mbox
- maildir is much slower than mbox over NFS (tried this a long time
ago with Kernel 2.0.* and Mutt)
- Don't forget, that /home is often mounted via NFS and there are also
mail folder in ~/Mail (or similar) which are filled using procmail.
So you have to use maildir for all these folders (which
exponentiates the above problems).
But every single Debian user is free to use Maildir on his system, for
example by using procmail (which comes with Maildir support in the
Debian package), so everybody _can_ use it, but nobody _must_ use it.
> The bad side of this is that it requires some very specific
> documentation, and it's an extra admin headache for people using
> mail on NFS. The good aspects are: (1) only affects people stuck
> with mail on NFS, and (2) people on those systems wouldn't lose mail
> to NFS "features".
It's a cleaner solution to simply fix the locking method. Miquel told
me that he will implement a NFS safe way of locking in liblockfile
(next week) and I proposed a policy change to make the problem clearer
(#43651, don't ask me, why only Joey Hess seconds this now).
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
