0001831: how do you get the timestamp resolution of a symlink? - Austin Group Defect Tracker

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???

(cries)

Tags

No tags attached.

Relationships

has duplicate

Closed

ajosey

1003.1(2008)/Issue 7

pathconfat() is missing

Notes
(0006780) philip-guenther (reporter) 2024-05-15 17:11	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. :)

(0006783) philip-guenther (reporter) 2024-05-18 05:57	OpenBSD 7.6 will have long pathconfat(int fd, const char *path, int name, int flag); where the flag argument supports AT_SYMLINK_NOFOLLOW.

(0006792) 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