Bug 17761 - Bug in rename().
Bug in rename().
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-09-21 00:29 EDT by Sam Varshavchik
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-09-21 00:30:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Shell script to demonstrate the bug. (483 bytes, text/plain)
2000-09-21 00:30 EDT, Sam Varshavchik
no flags Details

  None (edit)
Description Sam Varshavchik 2000-09-21 00:29:46 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.
Comment 1 Sam Varshavchik 2000-09-21 00:30:12 EDT
Created attachment 3482 [details]
Shell script to demonstrate the bug.
Comment 2 Stephen Tweedie 2000-09-25 10:14:10 EDT
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.)

Note You need to log in before you can comment on or make changes to this bug.