View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001831 | 1003.1(2016/18)/Issue7+TC2 | System Interfaces | public | 2024-05-15 08:10 | 2024-05-20 16:25 |
| Reporter | philip-guenther | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | New | Resolution | Open | ||
| Name | Philip Guenther | ||||
| Organization | OpenBSD | ||||
| User Reference | |||||
| Section | pathconf | ||||
| Page Number | 902-907 | ||||
| Line Number | 30519 | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0001831: how do you get the timestamp resolution of a symlink? | ||||
| Description | The description of pathconf() doesn't contain any specific wording about how it should handle a path which names a symlink. Contrast rename()'s description which says If either the old or new argument names a symbolic link, rename() shall operate on the symbolic link itself, and shall not resolve the last component of the argument. and unlink()'s description which says If path names a symbolic link, unlink() shall remove the symbolic link named by path and shall not affect any file or directory named by the contents of the symbolic link. It thus appears that pathconf() is expected to completely follow symlinks and report the values appropriate for the final result of the pathname resolution. However, it would be useful to be able to get the timestamp resolution (_PC_TIMESTAMP_RESOLUTION) for a symlink, even if it's dangling or points to a path on a filesystem with a different timestamp resolution. (This was encountered when trying to fix a pax implementation's handling of timestamp comparison for -u when the target filesystem had courser resolution that the source filesystem by using pathconf(_PC_TIMESTAMP_RESOLUTION) on the target path to handle the loss of high-precision time info...but the symlink pointed to a location with high-precision timestamps so it couldn't know to round the times when doing the comparison...) | ||||
| Desired Action | Got me! Change pathconf() to never follow a final symlink, ala rename(), unlink(), open(O_NOFOLLOW)? Never follow a terminal symlink when the second argument is _PC_TIMESTAMP_RESOLUTION? A new _PC_TIMESTAMP_RESOLUTION_NOFOLLOW??? (cries) | ||||
| Tags | No tags attached. | ||||
|
|
With a fresh cup of coffee, it's 'obvious' the correct action is to use pathconfat(AT_FDCWD, path, _PC_TIMESTAMP_RESOLUTION, AT_SYMLINK_NOFOLLOW) This was touched on in https://austingroupbugs.net/view.php?id=786 (c.f. Geoff's comment 2827 from 2015) so maybe I should just implement this in OpenBSD and drag everyone else along from there. :) |
|
|
OpenBSD 7.6 will have long pathconfat(int fd, const char *path, int name, int flag); where the flag argument supports AT_SYMLINK_NOFOLLOW. |
|
|
Closing 786 as a duplicate of this, since this is more up to date and refers to an implementation that is expected to exist by the time this is standardized. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-05-15 08:10 | philip-guenther | New Issue | |
| 2024-05-15 08:10 | philip-guenther | Name | => Philip Guenther |
| 2024-05-15 08:10 | philip-guenther | Organization | => OpenBSD |
| 2024-05-15 08:10 | philip-guenther | Section | => pathconf |
| 2024-05-15 08:10 | philip-guenther | Page Number | => 902-907 |
| 2024-05-15 08:10 | philip-guenther | Line Number | => 30519 |
| 2024-05-15 17:11 | philip-guenther | Note Added: 0006780 | |
| 2024-05-18 05:57 | philip-guenther | Note Added: 0006783 | |
| 2024-05-20 16:21 | nick | Relationship added | related to 0000786 |
| 2024-05-20 16:22 | nick | Relationship replaced | has duplicate 0000786 |
| 2024-05-20 16:25 | nick | Note Added: 0006792 |
