Inconsistent return code from rename(foo, bar), where foo and bar are links to the same file. If foo and bar are in the same directory, rename() fails. If foo and bar are in different directories, where one directory is NOT a parent of another directory (siblings), rename() fails, but returns 0. See the following attachment.
Created attachment 3482 [details] Shell script to demonstrate the bug.
It's all working fine. There was a bug in the test script provided: ln subdir1/a subdir2/b perl -e 'print "rename() returned: " . rename("subdir1/a", "subdir/b") . "\n";' Note the "subdir/b" in the rename call, which should be "subdir2/b". Fixing this produces entirely consistent results, with rename succeeding in both cases, and the system call returning zero: strace -f produces the output rename("a", "b") = 0 rename("subdir1/a", "subdir2/b") = 0 with both files left intact, as mandated both by POSIX and SingleUnix. See http://www.opengroup.org/onlinepubs/007908799/xsh/rename.html for the full, gory, brain-dead specification for rename. It includes the requirement that If the old argument and the new argument both refer to, and both link to the same existing file, rename() returns successfully and performs no other action. I'm guessing that perl is converting the "0" success return from the kernel syscall into a "1" success return from the perl rename function. The strace output is unambiguous --- the kernel is correctly returning 0 in both cases. (NB. strace on the original, buggy test script results in rename("subdir1/a", "subdir/b") = -1 ENOENT (No such file or directory) as the result of the illegal second rename, as expected.)