Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mtunx!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: <1126@mcgill-vision.UUCP>
Date: 2 Jun 88 09:16:32 GMT
References: <9312@eddie.MIT.EDU> <11658@mimsy.UUCP>
Organization: McGill University, Montreal
Lines: 51
Posted: Thu Jun  2 05:16:32 1988

In article <11658@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> In article <9312@eddie.MIT.EDU> nathan@eddie.MIT.EDU (Nathan Glasser) writes:
>> On my vax running 4.3bsd ... rename("foo","foo"); ...
>> will remove the file foo.
> Sounds like you have a hacked 4.3BSD.  From /sys/sys/ufs_syscalls.c:
> [code intended to shortcircuit renaming a file to itself]

I tried this on various systems, and in the presence of NFS.  The
machines involved are:

	apollo:	Sun-3 running Sunix 3.5
	    (not an Apollo machine, but a Sun called "apollo")
	ra: another Sun-3 also running Sunix 3.5
	larry: VAX 750 running mtXinu 4.3+NFS
	curly: MicroVAX-II running Berkeley 4.3, with my NFS server

Apollo:
    Local filesystem: rename fails, errno is set to -1 (!).
    Ra's filesystem: same as local.
    Larry's filesystem: same as Larry with local filesystem.
    Curly's filesystem: same as Curly with local filesystem.
Larry:
    Local filesystem: file disappears (original poster's position).
    Apollo's filesystem: same as Apollo with local filesystem.
    Curly's filesystem: same as Curly with local filesystem.
Curly:
    Local filesystem: no error, file remains (Chris' claim)

So it seems that NFS renames aren't locally checked, but are shipped
over to the remote system to be interpreted there.  On the basis of
this, I made one more NFS test.  The client was larry, the server was
an Ultrix 2.x machine (not sure of the minor version number).  Ultrix
seems to have gotten this right: the rename succeeded but didn't
destroy the file.

Both Sun and mtXinu seem to be broken.  Sun at least causes the rename
to fail, though they return an undocumented value for errno as it does
so.  mtXinu's failure is the most dangerous.  Chris' claim is correct,
as usual, though it was arguably reasonable for the original poster to
claim to be running "4.3" if the system was actually something similar
to the above (a vendor modification of real 4.3).

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!  (Not all implementations; note the Ultrix test.  DEC
got this one right - a kudos or two to them.)

					der Mouse

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