2017-06-08 03:37:30 +0700, Robert Elz: > Date: Wed, 7 Jun 2017 20:56:17 +0100 > From: Stephane CHAZELAS <stephane.chaze...@gmail.com> > Message-ID: <20170607195617.gf5...@chaz.gmail.com> > > | I imagine that text was there for some reason. > > I have always thought that what was important was the "one" and that > the main purpose of that language was to prevent two entries for ",." > or "." ever being returned. That is, to prevent an implementation > simply synthesising entries for "," and ",." and then returning whatever > is in the directory, which might also include one or (usually) both of > "." and "..", which would otherwise be the easy way to guarantee that > a "," and a ".." always exist, even when some filesystems on the system > implement those as directory entries, and others do not. [...]
Thanks. That's another interesting interpretation. So you're saying it may mean: > Implementations may synthesize "." and/or "..", but if they > do, they should be careful to make sure that those are > returned only once. That interpretation seems a bit far fetched to me. Also, I wouldn't expect that kind of "tip to developer" to be found in a normative section. I can see that text was already there at http://archive.opengroup.org/publications/archive/CDROM/c435.pdf (1994, I don't think I have access to older POSIX/Unix related specifications), but marked "EX" (extension) there which doesn't tie up with that interpretation I would say (a tip can't be "extended"). 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 "..")). That would make Linux+glibc systems (on ext4 file systems at least) non-compliant. There's this text in the rationale section of opendir() that was not there in c435 above (nor susv2: http://pubs.opengroup.org/onlinepubs/7908799/xsh/opendir.html, apparently added in susv3: http://pubs.opengroup.org/onlinepubs/009695399/functions/opendir.html): SUSv4TC1> The directory entries for dot and dot-dot are optional. SUSv4TC1> This volume of POSIX.1-2008 does not provide a way to test SUSv4TC1> a priori for their existence because an application that is SUSv4TC1> portable must be written to look for (and usually ignore) SUSv4TC1> those entries. Writing code that presumes that they are the SUSv4TC1> first two entries does not always work, as many SUSv4TC1> implementations permit them to be other than the first two SUSv4TC1> entries, with a "normal" entry preceding them. There is SUSv4TC1> negligible value in providing a way to determine what the SUSv4TC1> implementation does because the code to deal with dot and SUSv4TC1> dot-dot must be written in any case and because such a flag SUSv4TC1> would add to the list of those flags (which has proven in SUSv4TC1> itself to be objectionable) and might be abused. Which suggests some applications have assumed "." and ".." were first (which historically must have been the case as they were always the first entries created and directories would have been simple linear structures) and may explain why the spec would attempt to require it for XSI. 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. Should we expect readdir() to make sure only one entry is returned for a given filename by the way? -- Stephane
