This has some rather strange consequences, no, for all programs that
create a file read only and then change it to rw and write to it? It
means that nfs cannot be treated as an ordinary fs (well, I know about
the tricks with mkdir foo;cd, etc., which can also distinguish).
(I'll cc: this to the list now, since it looks like this is of global
interest)
I notice that the file corruption we see has the first half of the file
ok, then it stops abruptly. You are saying that the change to read-only
occured before the nfs write finished, I gather, and that the rest of the
write then failed. Is this a bug for tar then? Can I mount nfs's
specifying that I want synced data and meta data (i.e. serialized)
writes. What happens if I make a file ro while writing to it on a
_local_ file system? I don't think that change should be seen by the
process that opened the file rw.
I.e. it looks a bit like a bug still, not necessarily of nfs, though
perhaps nfs provides the circumstances that make it more visible.
Is there a work arround obvious to you?
This problem may be distinct from that of the user who was
getting "rubbish blocks" in their 17M nfs mounted Inbox.
Thanks for the help
Peter ptb@it.uc3m.es
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html