Bug 17761 - Bug in rename().
Summary: Bug in rename().
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-09-21 04:29 UTC by Sam Varshavchik
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-09-21 04:30:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

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") .

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.