Anonymous | Login | 2024-03-28 17:36 UTC |
Main | My View | View Issues | Change Log | Docs |
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 | 2019-06-10 08:55 | ||
Reporter | jrn | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
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 | |||||||
|
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |