On Dec 10, 2011, at 12:06 18PM, Mouse wrote:
>>> According to the online OpenGroup specification for read(2)
>>> available at [1], read(2) on directories is implementation
>>> dependant. If unsupported, it shall fail with EISDIR.
>
>>> Not all our file systems comply, and return random errno values in
>>> this case (mostly EINVAL or ENOTSUP).
>
> How does that not comply with "implementation dependent"? From a
> standards-conformance point of view, that's equivalent to "in this
> implementation, read(2) on directories is supported: on $FILESYSTEM, it
> always returns EINVAL, on $OTHER_FILESYSTEM, it works according to
> $REFERENCE; on $THIRD_FILESYSTEM, it always returns EOPNOTSUPP".
>
> This is not to say that it shouldn't be cleaned up. Just that I don't
> think it's actually nonconformant.
As I red the text, whether or not you support it, and how it behaves
if you do, is up to you, i.e., is implementation-dependent. However,
if you do not support it, there's a particular error you're supposed
to return: EISDIR. Arguably, an implementation that sometimes allows
it and sometimes doesn't (NetBSD, depending on the file system in
question) can do what it wants, but I don't think that that will help
application writers.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
