Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000534 [1003.1(2008)/Issue 7] Shell and Utilities Editorial Clarification Requested 2012-01-04 23:16 2012-01-12 17:00
Reporter jrn View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Resolved  
Name Jonathan Nieder
Organization
User Reference
Section mv
Page Number 2955
Line Number 97307
Interp Status ---
Final Accepted Text See Desired Action.
Summary 0000534: unclear phrasing in "mv" regarding same source and destination file
Description I. Suppose I want to replace a hard link with a symlink without disturbing other processes that might want to use it:

 >file
 ln file link
 ln -s file link.tmp
 mv -f link.tmp link

Is this required to succeed? What guarantees, if any, are there concerning the state of "link" when all is said and done?

II. Similarly, suppose I do:

 >file
 ln -s file file.tmp
 mv -f file.tmp file

Is this required to succeed, and must "file" end up a symlink to itself?

III. How about this?

 >file
 ln file file2
 ln -s file link
 ln -s file2 link.tmp
 mv -f link.tmp link

Is this required to succeed, and must "link" end up as a symlink to file2 if it does?

Reading the mv specification, it seems to come down to what it means for two operands to name the same file in step (2).

If naming the same file means referring to the same inode after following symlinks (e.g., checked using stat()), that would mean that in example (III) above an implementation can succeed by removing link.tmp and leaving link as a symlink to "file" (step 2c).

I suspect the intent was rather for "name the same file" to mean referring to the same inode after path resolution (e.g., checked using lstat()). This would match the corresponding case in rename():

| If the old argument and the new argument resolve to either the same
| existing directory entry or different directory entries for the same
| existing file, rename() shall return successfully and perform no other
| action.

There might be some alternative non-buggy condition to use. See http://debbugs.gnu.org/6960 [^] for some thoughts on that subject.
Desired Action On line 97307, change "name the same existing file" to "resolve to either the same existing directory entry or different directory entries for the same existing file".
Tags tc2-2008
Attached Files

- Relationships

-  Notes
(0001091)
nick (manager)
2012-01-12 16:58

Geoff Clare commented on the mailing list:


I think the standard is clear what "name the same file" means.

The operands are pathnames, and the way that pathnames name files
is through the pathname resolution process.

Therefore "A and B name the same file" means "A and B resolve to
directory entries for the same file".

> Desired Action:
> On line 97307, change "name the same existing file" to "resolve to either
> the same existing directory entry or different directory entries for the
> same existing file".

I believe this change would not alter the requirements of the
standard, although I would not oppose the change since it improves
consistency in the wording between mv and rename().

- Issue History
Date Modified Username Field Change
2012-01-04 23:16 jrn New Issue
2012-01-04 23:16 jrn Status New => Under Review
2012-01-04 23:16 jrn Assigned To => ajosey
2012-01-04 23:16 jrn Name => Jonathan Nieder
2012-01-04 23:16 jrn Section => mv
2012-01-04 23:16 jrn Page Number => 2955
2012-01-04 23:16 jrn Line Number => 97307
2012-01-12 16:58 nick Interp Status => ---
2012-01-12 16:58 nick Final Accepted Text => See Desired Action.
2012-01-12 16:58 nick Note Added: 0001091
2012-01-12 16:58 nick Status Under Review => Resolution Proposed
2012-01-12 16:58 nick Resolution Open => Accepted
2012-01-12 16:59 nick Tag Attached: tc2-2008
2012-01-12 17:00 nick Status Resolution Proposed => Resolved


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker