Rename bug?

der Mouse mouse at mcgill-vision.UUCP
Thu Jun 2 19:16:32 AEST 1988


In article <11658 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
> In article <9312 at eddie.MIT.EDU> nathan at 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 at mcgill-vision.uucp
			arpa: mouse at larry.mcrcim.mcgill.edu



More information about the Comp.unix.questions mailing list