Rename bug?

[Greg Limes]

In article <1126 at mcgill-vision.UUCP> mouse at 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 at 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 at sun.com]