>>>>> " " == Raphael Manfredi <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
