Re: 2.4.3-ac9/4 - NFS corruption

Trond Myklebust
2001-05-02T11:25:25Z

>>>>> " " == 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