[4930] in Athena Bugs
Re: NFS rename() problem
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue May 15 20:48:04 1990
Date: Tue, 15 May 90 20:47:44 -0400
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Cc: bug-kernel@ATHENA.MIT.EDU
Cc: bugs@ATHENA.MIT.EDU
In-Reply-To: Jonathan I. Kamens's message of Tue, 15 May 90 19:57:35 -0400,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Tue, 15 May 90 19:57:35 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Sender: jik@pit-manager.MIT.EDU
5. The user's client program gets an error telling it that the rename
didn't happen, even though it did.
This really should be a high-priority item for us, since it is
possible for this bug to cause someone to lose lots of file. I'm
thinking in particular of a user running "folder -pack". The most
recent person to have this happen to him was Dennis Baron, just the
other day.
While we may or may not be able to reduce the NFS renaming bug to
"negligible" rates, one thing that we should definitely consider
robustifying the "folder" program so it won't lose if rename() returns a
misleading error. (Thus the cc to bugs; please remove responses that
shouldn't go to the bugs list.)
- Ted
P.S. Alternatively, we could consider it evolution in action for people
who use MH. (No, no, no.... don't flame me down.....) :-) :-) :-)
