Red Hat Bugzilla – Bug 17761
Bug in rename().
Last modified: 2008-05-01 11:37:58 EDT
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") .
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.)