Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cmcl2!beta!hc!ames!oliveb!sun!limes From: limes@sun.uucp (Greg Limes) Newsgroups: comp.unix.questions Subject: Re: Rename bug? Summary: fixed in 4.0 Keywords: strange rename errno Message-ID: <55239@sun.uucp> Date: 2 Jun 88 19:58:15 GMT References: <9312@eddie.MIT.EDU> <467@aiva.ed.ac.uk> <9341@eddie.MIT.EDU> <2144@rpp386.UUCP> <1128@mcgill-vision.UUCP> Reply-To: limes@sun.UUCP (Greg Limes) Organization: Sun Microsystems, Mountain View Lines: 51 In article <1126@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) discusses a problem with "rename", noting that on a Sun-3 running "Sunix" 3.5, the call 'rename ("foo", "foo")' returns an error and sets errno to -1. This seemed a bit strange to me, so I tried it. TESTBED: threefive, a Sun 3/50 running SunOS 3.5 /tmp: local filesystem /fouroh/tmp: NFS mounted from fouroh:/tmp fouroh, a Sun 3/60 running SunOS 4.0 /tmp: local filesystem /threefive/tmp: NFS mounted from threefive:/tmp "ren", a trivial utility: extern int errno; main (ac, av) int ac; char **av; { int rv = rename (av[1], av[1]); printf ("rename returns %d; errno is %d\n", rv, errno); } RESULTS: fouroh% ren /tmp/foo rename returns 0; errno is 0 fouroh% ren /threefive/tmp/foo rename returns -1; errno is -1 threefive% ren /tmp/foo rename returns -1; errno is -1 threefive% ren /fouroh/tmp/foo rename returns 0; errno is 0 Looks like der Mouse's conclusions are correct, in that the rename request is passed on to the host system; also, I have to agree that some implementations of NFS may have bugs, but in this case NFS is only transporting the strange error code from one system to the other so we can pretty much remove NFS from our list of possible culprits. We can also see from the above that, whatever the bug was, it is fixed in release 4.0 of SunOS. In article <1128@mcgill-vision.UUCP> der Mouse writes: >... I trust one written by a company out to make money even less. Funny, I would expect exactly the reverse. If the operating system does not work properly, the company gets bug reports and has to fix them (this costs bucks), and if the bugs are bad enough, the company starts to lose customers to competitors who can provide better functionality. Thus is it in the best interests of the for-profit corporation to provide software that is as reliable and bug-free as possible. -- Greg Limes [limes@sun.com]