Bug 273921 - rename(a,b) does not replace b if a and b are hard linked
Summary: rename(a,b) does not replace b if a and b are hard linked
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: All
OS: All
medium
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-01 15:44 UTC by Daphne Shaw
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-09-04 23:22:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Rename syscall problem demonstration (709 bytes, text/x-csrc)
2007-09-01 18:16 UTC, Daphne Shaw
no flags Details

Description Daphne Shaw 2007-09-01 15:44:15 UTC
Description of problem:

Normally, rename(a,b) replaces b with a.  However, if a and b are hard linked,
rename(a,b) exits successfully, but performs no action.

Version-Release number of selected component (if applicable):

kernel-2.6.22.4-65.fc7

How reproducible:

 touch file1
 ln file1 file2
 rename file1 file2 file1
 ls -l file1 file2 

strace on the 'rename' step shows the problem:

 rename("file1", "file2")                = 0

Expected results:

file1 should replace file2

Comment 1 Daphne Shaw 2007-09-01 18:16:46 UTC
Created attachment 184541 [details]
Rename syscall problem demonstration

I see this bug has been reassigned to util-linux.  Note that I'm filing a bug
against the rename syscall and not the rename command line tool.  I only used
to rename command line tool to demonstrate the syscall.

Here is a demonstration program that does not use the rename command line tool.

Note that the rename() succeeds, but leaves both "foo" and "bar" behind.

Comment 2 Chuck Ebbert 2007-09-04 23:22:59 UTC
Posix spec says this is correct:

"If the old argument and the new argument resolve to the same existing file,
rename() shall return successfully and perform no other action."

Comment 3 Daphne Shaw 2007-09-05 00:03:28 UTC
I disagree (as do the BSD people, it seems, as rename() there works the other
way).  The Posix language does indeed say what you quoted, however, it also adds
some clarifying language to the bit you quoted in the Rationale section:

  The specification that if old and new refer to the same file is intended to
  guarantee that:

  rename("x", "x");

  does not remove the file.

The clarification makes sense (renaming something to the same name doesn't make
sense).  Renaming something to another name does make sense, and it's very odd
that it wouldn't work just because the files happened to be linked to each
other.  Names have nothing to do with the links.


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