Yes, pretty much. I can't say why it's phrased as it is, I didn't write it. I lean towards some implementation was making unnamed dirents if the file system didn't have those as names, perhaps originally for 8" floppies or 9 track tapes, so something intended to preclude that was added in as short a paragraph that looked feasible. For low RAM machines I'd hope the standard wasn't trying to force extra dirent allocations, anyways, just require those that represent what is actually on the media.
On Wednesday, June 7, 2017 Stephane CHAZELAS <[email protected]> wrote: 2017-06-07 12:41:31 -0400, [email protected]: > 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
