View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000541 | 1003.1(2008)/Issue 7 | Base Definitions and Headers | public | 2012-02-07 00:11 | 2019-06-10 08:55 |
| Reporter | eblake | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted | ||
| Name | Eric Blake | ||||
| Organization | Red Hat | ||||
| User Reference | ebb.pathname_resolution | ||||
| Section | 4.12 Pathname Resolution | ||||
| Page Number | 112 | ||||
| Line Number | 3026 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | See 0000541:0001119 | ||||
| Summary | 0000541: pathname resolution of a symlink containing exactly // | ||||
| Description | The specified behavior of 'ln -s // double && ls -d double/dev' is that the resolution should prefix the remaining pathname '/dev' by the contents of the symlink '//', for an invocation of 'ls -d ///dev', which must behave like 'ls -d /dev'. But this is at odds with other statements in the standard for handling // in an implementation-defined manner. On the Cygwin environment (which isn't quite POSIX, but which does try to exploit the POSIX rule of having // be separate from /), pathname resolution of a symlink to either type of root directory elides all leading slashes from the remainder of the pathname; this behavior should be standardized. With the proposed change, it becomes clear that 'double///dev' forms the pathname '//dev', and not '/////dev' (aka '/dev/'), for further resolution. In the case of trailing slashes with a non-slash also in the symlink contents, the standard is clear that the extra slashes from the symlink contents and the rest of the pathname to be resolved will be treated as if they were a single slash, except for the slight possibility of an ENAMETOOLONG error if too many consecutive slashes appear. I did not think it worth trying to require implementations to elide these extra slashes in an effort to avoid ENAMETOOLONG errors. | ||||
| Desired Action | At line 3026 [XBD 4.12 Pathname Resolution], after: In all other cases, the system shall prefix the remaining pathname, if any, with the contents of the symbolic link. add: If the contents of the symbolic link consist solely of <slash> characters, then all leading <slash> characters of the remaining pathname shall be omitted from the resulting combined pathname, leaving only the leading <slash> characters from the symbolic link contents. | ||||
| Tags | tc2-2008 | ||||
|
|
Interpretation response ------------------------ The standard states that the characters in a symlink are prepended to the remainder of the pathname being resolved, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- This is not historic practice on implementation that support //hostname as a special case in pathname resolution. For implementation that don't treat // as special, this change has no effect on pathname resolution. Therefore, this change seems suitable as a technical corrigenda fix. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes listed in the Desired Action. |
|
|
Interpretation proposed 29 June 2012 for final 45 day review |
|
|
Interpretation approved 30 Aug 2012 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-02-07 00:11 | eblake | New Issue | |
| 2012-02-07 00:11 | eblake | Status | New => Under Review |
| 2012-02-07 00:11 | eblake | Assigned To | => ajosey |
| 2012-02-07 00:11 | eblake | Name | => Eric Blake |
| 2012-02-07 00:11 | eblake | Organization | => Red Hat |
| 2012-02-07 00:11 | eblake | User Reference | => ebb.pathname_resolution |
| 2012-02-07 00:11 | eblake | Section | => 4.12 Pathname Resolution |
| 2012-02-07 00:11 | eblake | Page Number | => 112 |
| 2012-02-07 00:11 | eblake | Line Number | => 3026 |
| 2012-02-07 00:11 | eblake | Interp Status | => --- |
| 2012-02-09 17:24 | eblake | Relationship added | related to 0000083 |
| 2012-02-09 17:40 | Don Cragun | Interp Status | --- => Pending |
| 2012-02-09 17:40 | Don Cragun | Note Added: 0001119 | |
| 2012-02-09 17:40 | Don Cragun | Status | Under Review => Resolved |
| 2012-02-09 17:40 | Don Cragun | Resolution | Open => Accepted |
| 2012-02-09 17:40 | Don Cragun | Desired Action Updated | |
| 2012-02-09 17:40 | Don Cragun | Tag Attached: tc2-2008 | |
| 2012-02-09 17:41 | Don Cragun | Final Accepted Text | => See 0000541:0001119 |
| 2012-02-09 17:42 | Don Cragun | Note Edited: 0001119 | |
| 2012-02-09 17:42 | Don Cragun | Status | Resolved => Interpretation Required |
| 2012-06-29 16:15 | ajosey | Interp Status | Pending => Proposed |
| 2012-06-29 16:15 | ajosey | Note Added: 0001289 | |
| 2012-08-30 09:14 | ajosey | Interp Status | Proposed => Approved |
| 2012-08-30 09:14 | ajosey | Note Added: 0001352 | |
| 2013-01-24 15:38 | eblake | Relationship added | related to 0000649 |
| 2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
