Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001831 [1003.1(2016/18)/Issue7+TC2] System Interfaces Objection Clarification Requested 2024-05-15 08:10 2024-05-20 16:25
Reporter philip-guenther View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
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???

Tags No tags attached.
Attached Files

- Relationships
has duplicate 0000786Closedajosey 1003.1(2008)/Issue 7 pathconfat() is missing 

-  Notes
philip-guenther (reporter)
2024-05-15 17:11

With a fresh cup of coffee, it's 'obvious' the correct action is to use

This was touched on in [^] (c.f. Geoff's comment 2827 from 2015) so maybe I should just implement this in OpenBSD and drag everyone else along from there. :)
philip-guenther (reporter)
2024-05-18 05:57

OpenBSD 7.6 will have
     pathconfat(int fd, const char *path, int name, int flag);

where the flag argument supports AT_SYMLINK_NOFOLLOW.
nick (manager)
2024-05-20 16:25

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.

- Issue History
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

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