2017-06-08 11:10:36 +0200, Joerg Schilling:
> Stephane CHAZELAS <stephane.chaze...@gmail.com> wrote:
>
> > Could it be that it means that "." and ".." should be returned
> > *first* when they're there on XSI systems? (which would be yet
> > another interpretation that is valid as an "extension" (non-XSI
> > are allowed to return other entries before "." and "..")).
>
> From what I can tell, "." and ".." must be returned first via readdir().
[...]
That's not what the opendir() text mentioned earlier says:
SUSv4TC2> The directory entries for dot and dot-dot are optional.
SUSv4TC2> This volume of POSIX.1-2008 does not provide a way to test
SUSv4TC2> a priori for their existence because an application that is
SUSv4TC2> portable must be written to look for (and usually ignore)
SUSv4TC2> those entries. Writing code that presumes that they are the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SUSv4TC2> first two entries does not always work, as many
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SUSv4TC2> implementations permit them to be other than the first two
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SUSv4TC2> entries, with a "normal" entry preceding them. There is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SUSv4TC2> negligible value in providing a way to determine what the
SUSv4TC2> implementation does because the code to deal with dot and
SUSv4TC2> dot-dot must be written in any case and because such a flag
SUSv4TC2> would add to the list of those flags (which has proven in
SUSv4TC2> itself to be objectionable) and might be abused.
Implementations that still do (waste space to) store those two
entries in the directory file format, but use structures like
hashed b-trees to store entries may very well return them in any
order. The fact that they were (usually) first in historical
implementations is more an accident of implementation.
> > IMO, the text about dot/dot-dot in readdir() should go (unless
> > someone can figure out what it's for), and maybe an "application
> > usage" section added to clarify that there's no guarantee that
> > entries for "." or ".." will be returned and that if they do,
> > they would not be guaranteed to be the first ones returned or in
> > that order.
>
> I still stand for the statement that a filesystem that does not either
> contain
> both entries or none of them is in a broken state.
I'd agree with that, but I can't think of a scenario where an
application would be broken when faced with a readdir()
implementation that returns one and not the other (which concurs
with the opendir() text above).
Generally, you just want to skip those "." and "..".
One could argue that they should never have been returned by
readdir() or maybe even been real directory entries.
It's ironic (in the context of my request to allow/recommend .*
not to include . and ..) that file names beginning with "." are
ignored by default by ls and globs because of a typo (according
to legend) in an early "ls" implementation that meant to skip
"." and ".." only but ended up skipping any filename starting
with ".".
Now we still want to skip "." and "..", but we also want it with
".*" (same reason there's a ls -A, why find doesn't list
them, why sensible (IMO) shells (pdksh, mksh, zsh, fish) never
include them in glob expansions).
While I generaly agree with kre in that I am not "in favour of
software attempting to second guess what it thinks the user
"almost always wants"", I don't think we're in such a case here
as "." and ".." are definitely not normal entries.
It would be like saying: find . -name '.*' should report all the
. and .. entries, because those entries are there and we don't
want "find" second-guessing that the user doesn't want them.
> > Should we expect readdir() to make sure only one entry is
> > returned for a given filename by the way?
>
> What scenario do you have in mind?
[...]
I'm just wondering if POSIX gives that guarantee.
If for instance a directory is being modified while an
application does several calls to readdir(), could different
entries for the same filename be returned?
--
Stephane
