View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000534 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2012-01-04 23:16 | 2019-06-10 08:55 |
| Reporter | jrn | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted | ||
| 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 | ||||
|
|
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(). |
| 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 |
| 2019-06-10 08:55 | agadmin | Status | Resolved => Closed |