0001603: minor error in the pathname resolution

Notes
(0005950) calestyo (reporter) 2022-08-30 23:50 edited on: 2022-08-30 23:51	I think there are further such cases: - line 2840, "in the pathname fragment a/b, file b is located in directory a", a might not be a directory, but also a symlink pointing to such - line 2875, "If the resulting pathname does not begin with a <slash>, the predecessor of the first filename of the pathname is taken to be the directory containing the symbolic link."... the predecessor could be a symlink, so shouldn't it somehow say that it's taken to be the target of such, if it is one? Cases where I think it's really just directory: - always when it says "directory entry" - line 2839, "Each filename in the pathname is located in the directory specified by its predecessor", because of the "specified" which a symlink also does Unsure: - line 2842, "root directory of the process" ... I'd assume the process root dir is always resolved already to a true directory?, just as the current working directory in line 2845? ... Similar in line 2888 So better some expert check these :-) (thx)

(0005951) calestyo (reporter) 2022-08-30 23:51	(put one point into the wrong category in comment 0005950 ... so please take the edited version from the website, not any email)

(0005952) geoffclare (manager) 2022-09-01 08:23	On the mailing list Lawrence Velázquez asked "Do lines 2857 through 2877 not address this sufficiently?" and Oğuz replied "They do". Whilst I agree that the requirements are clear when those lines are taken into account, I think some minor wording changes would be helpful. I suggest: On page 94 line 2839 change: Each filename in the pathname is located in the directory specified by its predecessor (for example, in the pathname fragment a/b, file b is located in directory a). to: Each filename in the pathname is located in the directory specified by its predecessor (for example, in the pathname fragment a/b, file b is located in the directory specified by a). On page 94 line 2851 change: unless the last pathname component before the trailing <slash> characters names an existing directory or a directory entry that is to be created for a directory immediately after the pathname is resolved. to: unless the last pathname component before the trailing <slash> characters resolves (with symbolic links followed - see below) to an existing directory or a directory entry that is to be created for a directory immediately after the pathname is resolved. I have not included any change for line 2875 - I believe "the directory containing the symbolic link" is fine. If this directory was arrived at via a symbolic link, it makes no difference as it is the directory itself that the text is referring to.

(0005953) calestyo (reporter) 2022-09-01 13:20	Hmm I guess it's clear for anyone who knows how it works, but maybe not so 100% in the definite sense. Take my original message about: "A pathname that contains at least one non-<slash> character and that ends with one or more trailing <slash> characters shall not be resolved successfully unless the last pathname component before the trailing <slash> characters names an existing directory or a directory entry that is to be created for a directory immediately after the pathname is resolved." That says basically: "if the last component before the trailing / is not a directory, then don't succeed" Now it's ambiguous at that point whether "names and existing directory" includes such referenced via a symlink or not. Sure, lines 2857 through 2877 explain what happens with symlinks, but they come only after the above paragraph. So - other than by knowing how it works - how could one tell that the symlink-rules still apply, and that resolution didn't already fail&stop because of the above? As for your proposed changes: It's IMO not really defined what "specified" means here. What would think about using a phrase like "in the directory named respectively referenced by a"? That kinda would indicate a bit more that there's two kinds here. Or perhaps the "resolves (with...) [to]" that you used in the other change?

(0005954) geoffclare (manager) 2022-09-01 13:46	Re Note: 0005953 (last part), in Note: 0005950 you said that the part of line 2839 before the parentheses was okay «because of the "specified" which a symlink also does», so I proposed changing the text inside the parentheses to match that. Seems fine to me.

(0005956) kre (reporter) 2022-09-01 16:17	Re Note: 0005953 The whole standard needs to be read as a unit, it isn't a tutorial, and you cannot simply pick a small section and read it in isolation and expect to correctly understand what it is saying. Paths are resolved left to right, the only way one discovers that something doesn't exist, is by attempting to find it in its parent directory. When that happens, if what is found is a symlink, then the symlink resolution rules apply, and we replace the symlink (and perhaps all that came before it) with the "value" of the symlink, and go back to resolving again. At this point we haven't looked beyond the '/' that terminated this pathname component, and have no idea at all that nothing more follows. That we only determine later. Normally anything followed by a '/' (after symlinks have been resolved) must be a directory, and must exist (obviously, or we would not know that it was a directory). But people, for reasons I never understood (I'd simply prohibit the practice) want to be able to do "mkdir /path/newdir/" when what they really mean is "mkdir /path/newdir". The final component, the one not followed by a '/', not existing when we are making something is normal, that is the name we want to create, not one that exists (though sometimes creating something which already exists is allowed, like open(path, O_CREATE)) and needs no special handling. mkdir /path/newdir/ is a very special weird case, which that paragraph quoted is dealing with. But nothing about the general process of pathname resolution varies, we still resolve what we can, just that special case applies, if a trailing "/" appears, then the preceding component is treated as the final one, instead of the empty string after the '/'. FWIW I agree with the people on the mailing list, no changes are needed for this one at all, not the ones proposed in Note: 0005952, nor any other. That doesn't mean that there's anything wrong with the Note: 0005952 proposed wording, though the 2nd proposed change reads rather clumsily, just that the changes aren't really needed.

Issue History
Date Modified	Username	Field	Change
2022-08-30 23:34	calestyo	New Issue
2022-08-30 23:34	calestyo	Name	=> Christoph Anton Mitterer
2022-08-30 23:34	calestyo	Section	=> 4.14 Pathname Resolution
2022-08-30 23:34	calestyo	Page Number	=> 94
2022-08-30 23:34	calestyo	Line Number	=> 2850 ff
2022-08-30 23:50	calestyo	Note Added: 0005950
2022-08-30 23:51	calestyo	Note Edited: 0005950
2022-08-30 23:51	calestyo	Note Added: 0005951
2022-09-01 08:23	geoffclare	Note Added: 0005952
2022-09-01 13:20	calestyo	Note Added: 0005953
2022-09-01 13:46	geoffclare	Note Added: 0005954
2022-09-01 16:17	kre	Note Added: 0005956
2022-09-01 16:17	kre	Note Added: 0005957
2022-09-02 03:51	kre	Note Deleted: 0005957
2022-10-20 16:28	geoffclare	Final Accepted Text	=> Note: 0005952
2022-10-20 16:28	geoffclare	Status	New => Resolved
2022-10-20 16:28	geoffclare	Resolution	Open => Accepted As Marked
2022-10-20 16:28	geoffclare	Tag Attached: tc3-2008
2022-11-01 15:05	geoffclare	Status	Resolved => Applied
2024-06-11 09:12	agadmin	Status	Applied => Closed

Relationships

Aardvark Mark IV