Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.31/text0083.txt

Text File | 1993-07-15 | 3.6 KB | 76 lines

Submitted-by: [e-mail] (Jason Zions)

Regarding the question of 1003.2 "grep -s" supressing EISDIR for
NFS-accessible directories:

NOTE 1
Remember that 1003.2 does *not* assume its pieces are running on a 1003.1-
conforming system. While it's not a bad idea to reason about 1003.2 behavior
from the standpoint of implementations on 1003.1-conforming systems, keep in
mind that such reasoning is not guaranteed to be reflected in the standard.

NOTE 2
When reasoning about 1003.1-conforming systems, please remember that a sys-
tem which so much as hints at the existence of files or directories accessed
via NFS is no longer strictly-conforming, since accessing files over NFS
doesn't yield the exact set of semantics required by 1003.1.  If you really
need a strictly-conforming system, don't configure NFS into the kernel.

[e-mail] (Michael I Bushnell) writes:
>>The real lose here (surprise, surprise) is that NFS is the culprit
>>here.  The correct place for the EISDIR to be returned is to the open
>>call, not to the read.  Errors should not be returned from read and
>>write if they can be detected at open time and are thoroughly
>>non-transient.

According to 1003.1-1990, EISDIR is only returned when opening a directory
for write or read/write; the standard is silent concerning opening
directories with O_READONLY. It's bad enough that NFS breaks read() (see
below); breaking open() too would have been awful.

[e-mail] (Casper H.S. Dik) writes:
>No. NFS is not the culprit. You cannot detect this at open time.
>When you read a directory, you'll open it with open and read it
>with getdents(). When you open a file for reading, you'll use the
>exact same open call. You cannot detect this error at open time.

When you read a directory in POSIX, you open it with opendir() and read it
with readdir(). That's it; no open(), no getdents().

In this case NFS is indeed the culprit; it breaks the 1003.1 behavior of
allowing an application to read() from a directory. This restriction is
arbitrary; the NFS protocol itself allows it. Making read() fail on
NFS-accessed directories was a tool to catch programs that examined
directories using read() and assuming they knew what the actual structures
in the directory looked like. In a POSIX environment, this restriction is
unnecessary; conforming POSIX applications never try that, using the 1003.1
interfaces instead.

In fact, when 1003.8 (POSIX Transparent File Access) sees the light of
publicationand legitimizes NFS under POSIX (so to speak), this restriction
will *have* to go away if one wishes to claim ones implementation conforms
to 1003.8.  Strictly conforming applications don't try to read() directories
with the assumption that they're doing something equivalent to readdir(),
since the standard doesn't say they can; however, a strictly-conforming
application is allowed to read() a directory for any purpose.

In any event, I'd suspect that the spirit of 1003.2, interpreted with
respect to a 1003.1 implementation that also supports NFS files, would be
that "-s" would suppress EISDIR on a directory, since those implementations
really do place directories in the category of "You can't read this".

However, you should file a Request for Interpretation; contact the IEEE
Standards Department for specific instructions on how to do this. It's a
formal process; until you get an interpretation, anything you hear from
anyone, even the chair or tech editor of 1003.2, is mere opinion.

As usual, I am speaking as an individual technical expert, *not* as a
spokesperson for 1003.8, POSIX, PASC, IEEE-CS, IEEE, etc.

Jason Zions
Chair, 1003.8 POSIX Transparent File Access


Volume-Number: Volume 31, Number 85