View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000786 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2013-11-04 21:57 | 2024-05-20 16:25 |
| Reporter | joerg | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Closed | Resolution | Duplicate | ||
| Name | Jörg Schilling | ||||
| Organization | FOKUS Fraunhofer | ||||
| User Reference | |||||
| Section | 3 System Interfaces | ||||
| Page Number | 893 | ||||
| Line Number | 29895-29905 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000786: pathconfat() is missing | ||||
| Description | We need a universal system for path name based interfaces. As we have openat(), we also need pathconfat(). | ||||
| Desired Action | after line 29900 add: lonf pathconfat(int fd, const char *oath, int name); after line 29905 add: The pathconfat() function shall be equivalent to the pathconf() function except in the case where path specifies a relative path. In this case the file to be checked is determined relative to the directory associated with the file descriptor fd instead of the current working directory. If the file descriptor was opened without O_SEARCH, the function shall check whether directory searches are permitted using the current permissions of the directory underlying the file descriptor. If the file descriptor was opened with O_SEARCH, the function shall not perform the check. If pathconfat() is passed the special value AT_FDCWD in the fd parameter, the current working directory shall be used and the behavior shall be identical to a call to pathconf(). If pathconfat() is passed a NULL pointer for path, pathfonfat() acts like fpathconf(). | ||||
| Tags | No tags attached. | ||||
| duplicate of | 0001831 | New | 1003.1(2016/18)/Issue7+TC2 | how do you get the timestamp resolution of a symlink? |
|
|
Is there existing practice? If not, then I highly suggest adding an 'int flags' parameter. One of the real powers of openat(), but where mkdirat() falls short, is the extensibility offered by having a flags parameter as part of the interface. Also, none of the existing *at() functions mandate behavior for a NULL path, instead choosing to leave this for implementation extensions; I see no reason why we should operate any differently for pathconfat(). |
|
|
I think this is a duplicate request from Issue 6. The consensus then IIRC was as fpathconf() was provided the application could use open() or openat() to get a fd for use with that to block race conditions, which is possible while a call to pathconf(), and other interfaces with at() variants, is in progress. The corner case where this interface would be needed, when OPEN_MAX descriptors were already in use by the application, was considered insufficient reason to add this to Issue 7. I thought it was sufficient but was outvoted. That's my recollection. So now there's two votes for it :-) I agree with adding the flags parameter, to support AT_SYMLINK_NOFOLLOW as some other *at() interfaces do. I could see that flag being a sysconf() system option addition or session global shell option, actually, but that's a separate issue. Current practice is some interfaces that deal with paths are allowed to have it as a per-call option and it wouldn't hurt with this one. Also, I read mkdir() and mkdirat() as they 'shall fail' with ENOENT when the path argument is NULL, as there's no language overriding C's default of NULL char * dereferences being treated as char * to '/0' and it never resolves to a valid path, according to XBD 4.12. Most other interfaces I checked that have a char *path argument have this error case as 'shall fail' too. This implication may be considered non-binding in some respects (glibc returns EINVAL instead for mkdirat() ), and it's a 'may fail' for pathconf(), but it seems to be the intent. The only extension I could think of offhand that might be of use is for an interface that fills in a structure with path specific data, like fstatat(), using a NULL argument as a command to fill it with non-zero default data. For this I think the proposed behavior for NULL to override the 'may fail' case is reasonable enough. |
|
|
I have no problems with adding a flag argument to the function, there is no existing code yet. I stepped over the problem recently while enhancing star to support NFSv4 ACLs and thinking about adding support for arbitrary long path names in the future. When I am going to do this, I would need pathconfat() as it needs to be called before/without calling open() in many cases. For this reason, fpathconf would not work here. BTW: the *at() group of interfaces was first introduced in Summer 2001 on Solaris and Solaris implements the NULL pointer behavior in question with related *at() interfaces. |
|
|
Could the author of note 0001958 clarify the text: "as there's no language overriding C's default of NULL char * dereferences being treated as char * to '/0' and it never resolves to a valid path"? As written it makes no sense, and I have not been able to make any interpretation of it that agrees with anything in the C or POSIX standards. |
|
|
This was discussed on the 19 Dec 2013 teleconference; while there is consensus that the interface would be useful to have, we are reluctant to standardize it without first having interface practice. For now, we will leave the issue open, with the intent to revisit it later when there is an existing implementation. Note that the interface proposed in the Desired Action may be insufficient; the need for a flags argument should be investigated, as well as consideration for any interface named fpathconfat(). Also note that FreeBSD has lpathconf(), which may be a subset of the functionality proposed for pathconfat(). |
|
|
Re: 1967 You are correct it is not part of the standard, per se, so I was probably thinking of a particular implementation that defined that behavior where the standard leaves it undefined in Section 7.1.4, #1. Sorry for the confusion, but I did think it was in there at the time. As I've used or tried out a lot of different versions of C by various vendors in over 30 years things do blur together sometimes, so can't say for certain which version that may have been. As many of the str* interfaces in POSIX also don't define error codes for an argument being NULL that convention is at least reasonable for source arguments and some destination ones too, so the function provides consistent results, and avoids memory access faults by not trying to read or write location 0. |
|
|
If we don't add pathconfat(), with a flags argument, then we should add FreeBSD's lpathconf(). Reason is that the standard currently lacks any way to query the timestamp resolution of a symlink. In practice it is probably reasonably safe to use the timestamp resolution of the directory containing the symlink, but the standard does not require them to be the same. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-11-04 21:57 | joerg | New Issue | |
| 2013-11-04 21:57 | joerg | Status | New => Under Review |
| 2013-11-04 21:57 | joerg | Assigned To | => ajosey |
| 2013-11-04 21:57 | joerg | Name | => Jörg Schilling |
| 2013-11-04 21:57 | joerg | Organization | => FOKUS Fraunhofer |
| 2013-11-04 21:57 | joerg | Section | => 3 System Interfaces |
| 2013-11-04 21:57 | joerg | Page Number | => 893 |
| 2013-11-04 21:57 | joerg | Line Number | => 29895-29905 |
| 2013-11-04 22:12 | eblake | Note Added: 0001957 | |
| 2013-11-05 08:34 | shware_systems | Note Added: 0001958 | |
| 2013-11-05 08:35 | shware_systems | Note Edited: 0001958 | |
| 2013-11-07 14:16 | joerg | Note Added: 0001966 | |
| 2013-11-07 16:30 | dalias | Note Added: 0001967 | |
| 2013-12-19 16:57 | eblake | Interp Status | => --- |
| 2013-12-19 16:57 | eblake | Note Added: 0002086 | |
| 2013-12-19 16:57 | eblake | Resolution | Open => Future Enhancement |
| 2013-12-19 17:02 | eblake | Note Edited: 0002086 | |
| 2014-01-08 14:23 | shware_systems | Note Added: 0002095 | |
| 2015-09-11 15:47 | geoffclare | Note Added: 0002827 | |
| 2024-05-20 16:21 | nick | Relationship added | related to 0001831 |
| 2024-05-20 16:22 | nick | Relationship replaced | duplicate of 0001831 |
| 2024-05-20 16:25 | Don Cragun | Status | Under Review => Closed |
| 2024-05-20 16:25 | Don Cragun | Resolution | Future Enhancement => Duplicate |
