Quoting Trond Myklebust <[EMAIL PROTECTED]> from ml.linux.kernel:
:>>>>> " " == Raphael Manfredi <[EMAIL PROTECTED]> writes:
: > An "ls -l" on the file yields:
:
: > -rw------- 1 ram users 1642491 May 1 00:00 inbox
:
: > (on the server, and via NFS), which is *abnormal*, since it's
: > 15:18 and I've just updated the file. Therfore, the timestamp
: > is corrupted as well in the inode.
:
:In that case you have some other task that has done a 'touch' or
:something to the file. An NFS client does not explicitly set the
:timestamp when doing ordinary reading/writing to a file - it leaves it
:to the server to do so.
Of course, I understand that. It's *abnormal* because I told "mutt"
to delete a message from the mailbox, and then re-synchronized it,
thereby writing to it. I expected the timestamp to be updated on
the server after that operation. It did not happen.
:Would you happen to be delivering mail to the same file on the server
:or something like that?
Yes, mail is delivered on the server by mailagent, so with proper local
locking.
: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?
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.
Raphael
-
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/
