Re: 2.4.3-ac9/4 - NFS corruption

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Raphael Manfredi <Raphael_Manfredi@pobox.com> writes:

     > Yes, mail is delivered on the server by mailagent, so with
     > proper local locking.

That's not good enough. The NFS client needs to know when it is in
sync with the server...

     > :If so it's completely normal behaviour: the userland NFS
     > doesn't :support file locking, so there's no way that the
     > client can guarantee :that some task on the server won't write
     > to the file behind its :back...

     > Does kernel-land NFS support file locking?

Yes. See the NFS-HOWTO for details.

     > In any case, "mutt" does not lock the file, so yes, I'm
     > perfectly aware there could be a race.  But not the kind of
     > race that would NULL-ify 5 bytes on the file when read from the
     > client, whilst those same bytes are perfectly normal when read
     > from the server.

That can easily happen if the client thinks that the file is longer
than it is on the server. A client has to rely on its cached value of
the file length in order to append to a file, since it has to specify
an offset at which to write. If that offset exceeds the current file
length, the server does the equivalent of a truncate() to extend the
file.

See RFC1094 and RFC1813 for further details on how NFS implements
reading and writing...

Cheers,
   Trond