Bug 17761

Summary: Bug in rename().
Product: [Retired] Red Hat Linux Reporter: Sam Varshavchik <mrsam>
Component: kernelAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: sct
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-09-21 04:30:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Shell script to demonstrate the bug. none

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