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