Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!killer!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.questions
Subject: Re: Rename bug?
Message-ID: <1132@mcgill-vision.UUCP>
Date: 4 Jun 88 09:00:25 GMT
References: <9312@eddie.MIT.EDU> <11658@mimsy.UUCP> <1126@mcgill-vision.UUCP> <55225@sun.uucp>
Organization: McGill University, Montreal
Lines: 34
Posted: Sat Jun  4 05:00:25 1988

[ >> = me, writing about how rename("foo","foo") works and/or fails ]
[ > = Guy Harris ]
>> Yet more reason not to use NFS: implementations of it tend to be
>> broken.  In this case it's even worse: the breakage shows even when
>> NFS is not in use!
> Umm, in the SunOS 3.5 case, the conclusion that it's an NFS bug
> cannot be drawn from the evidence.  Calling an NFS problem, given
> that it shows up "even when NFS is not in use", is a bit silly.  In
> fact, it was a bug in the *UFS* code,

This much was clear from the fact that it worked/failed the same for
any given filesystem regardless of whether the filesystem was accessed
over NFS or locally.

> and had nothing whatsoever to do with NFS.

This I argue with, see below.

> The bug was introduced by a bug fix to what is, I suspect, the bug
> you saw in the Mt. Xinu system, where rename("foo", "foo") causes
> "foo" to disappear.  If this is the case with the Mt. Xinu system,
> it's another UFS bug, not an NFS bug.

When I called it a reason not to use NFS, I didn't say it was an NFS
bug.  It is a bug in an NFS-capable kernel which wouldn't exist if it
weren't for the NFS capability.  In that sense, NFS is responsible for
it, and that is the sense in which I meant my comment about NFS.  I
consider the whole vfs-based filesystem as an NFS thing, since it
exists only to support NFS.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu