2017-06-07 12:41:31 -0400, shwares...@aol.com:
> Because of the 'dot or dot-dot', not 'dot and dot-dot', I construe 'they'
> as "one or the other, or both if both missing" shall not be returned. You
> don't synthesize an unnamed or assigned name record for one that isn't
> present, to relate it to rest of paragraph. This may be off, I can see why
> you
> feel the way you do, but it is consistent with the -a and -A descriptions
> for ls. Both or none only isn't.
[...]
So you're saying that the
SUSv4TC2> If entries for dot or dot-dot exist, one entry shall be
SUSv4TC2> returned for dot and one entry shall be returned for
SUSv4TC2> dot-dot; otherwise, they shall not be returned.
Is to be read as
> If entries for dot or dot-dot exist, one entry shall be
> returned for dot if it exists and one entry shall be returned for
> dot-dot if it exists; otherwise, they shall not be returned.
But then, that would mean that "." and ".." would be treated
just the same as any other entry, and there would be no need for
such a convoluted piece of text. I can't imagine someone would
have come up with such a text just to say . and .. were not to
be treated specially.
I imagine that text was there for some reason. Your
interpretation is not convincing me.
Note that as Geoff said, "." and ".." as a path always exist
(opendir(".") always works whether there's a "." entry in the
current directory or not) (except maybe for "/.."), so
synthesizing them in the return of readdir() should be fine. I
imagine there was a good reason to make sure readdir() did not
return "." without ".." or ".." without ".", possibly some good
reason that made sense in the 80s but that most people have now
forgotten.
By the way, on Solaris 11:
s11:/system/zones$ ls -lia
total 6
4 drwxr-xr-x 2 root root 2 Jun 25 2014 ./
4 drwxr-xr-x 7 root root 7 Jun 25 2014 ../
s11:/system/zones$ ls -lid ..
9 drwxr-xr-x 7 root root 7 Jun 25 2014 ../
/system/zones is a mountpoint. See how the inode number for ".."
is different in both cases. Note that the "4" inode number (in
the output of ls -ia) seems to be coming from getdents(2) (so
from the directory entry in the root directory of that
filesystem mounted on /system/zones) but the "7" size (and
permissions, uid, gid, mtime) seems to be coming from stat() (so
from the directory at the ".." path (the parent of /system/zones
in the directory tree, so the /system directory (with inode 9)
in the file system mounted on /).
Is that the behaviour expected by POSIX?
BTW, a separate issue with the "ls" specification.
About the "total" header line in the ls -l output, the text has:
SUSv4TC2> [...]each list of files within the directory shall be preceded by a
SUSv4TC2> status line indicating the number of file system blocks occupied
SUSv4TC2> by files in the directory in 512-byte units[...]
That's not what I observe with the several implementations I've
tried. Instead, I only see the sum of blocks for the listed
files (so not counting hidden files without -a, and not counting
. nor .. with -A). When there are several hard links to the same
files, I also see the number of blocks of that file counted
several times.
--
Stephane
