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