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
0001603 [Issue 8 drafts] Base Definitions and Headers Editorial Enhancement Request 2022-08-30 23:34 2022-11-01 15:05
Reporter calestyo View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied   Product Version Draft 2.1
Name Christoph Anton Mitterer
Organization
User Reference
Section 4.14 Pathname Resolution
Page Number 94
Line Number 2850 ff
Final Accepted Text Note: 0005952
Summary 0001603: minor error in the pathname resolution
Description Hey.

Pathname resolution says:
"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."

But shouldn't it also resolve successfully when the last pathname component before the trailing <slash> characters names a symbolic link pointing to a existing directory?

Not sure if one should also allow a dangling symlink if the directory is to be created? I guess rather not because e.g.
$ ln -s non-existing dangling
$ mkdir -p dangling/sub

fails and probably should do so
Desired Action In line 2852, after:
   "names an existing directory"
insert
   " or symbolic link that points to such"
Tags tc3-2008
Attached Files

- Relationships

-  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


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