finding NFS dirs in csh?

[der Mouse]

In article <10398 at sun.uucp>, guy at sun.uucp (Guy Harris) quotes:
>> NFS breaks the directory-as-a-file paradigm
and writes:
> DIRECTORIES AREN'T FILES!!!!!!!!  They may happen to be implemented
> on UNIX in such a fashion that they can be treated as such in some
> cases, but they can't always be treated as such.

Directories are, conceptually, not files.  However, I know of no
operating system on which a directory is *not* a file, albeit usually
with an imposed format and special flags set in its inode analogue.

> When you read a directory entry, you want [certain numbers] to be
> presented in the format of the machine and operating system doing the
> *reading*, *not* the format of the machine and operating system on
> which they are stored.

Sounds like a good reason not to mix big-endian and little-endian
machines on a LAN.  Sigh, if only the world could agree on a byte
order....if everyone else went, I would even be willing to switch.

> As such, you must use a system call that knows you're trying to read
> directory entries,

Read() certainly has that information available.  It can look at the
inode and say "hey, this call is reading from a directory!".  Just
because it hasn't had to historically doesn't mean it isn't allowed to.

> so that they can be put into a standard form at the sending site and
> put into the native form at the receiving site.

EXACTLY.  *Why* can't you just present a directory in what has always
been the standard form - read() returning directory entries?  You can
ship it around the net however you like - I'm not fussing about NFS
using a different rpc call to read directory entries, I'm talking about
the user program level.

Todd Brunhoff's RFS did this right; when read() is done on a directory
it notices and byteswaps the i-numbers.  What I would like to see NFS
do is get the directory entries (how is immaterial) and then construct
something that looks like what a local directory looks like.

> If "read" worked on directories over NFS, any program that tried to
> use "read" to read directory entries from a directory, rather than
> "getdirentries" (SunOS) or "getdents" (System V, Release 3, and
> probably some future SunOS release) would be quite likely to get
> wrong answers.

Only if read() weren't careful to check whether it's reading a
directory.

>> so an attempt to open() and read() a directory will produce errors.
>> Since standard I/O insulates programs from these errors,
> Standard I/O does no such thing.  [...]  The program can then use
> "ferror" or "feof" to distinguish between error and EOF.

Bad choice of words on my part.  Lots of programs (eg, cat) simply do
something like
	while ((c=getchar()) != EOF)
assuming that EOF means eof (a very easy trap to fall into).

>> a remote directory will look like an empty file to many programs.
> Only to *broken* and *incorrect* programs, i.e. programs that assume
> that any error/EOF indication from standard I/O is an EOF indication.
> Such programs should be fixed!

Easy to say.  There are a lot of such programs.  Even your SunOS (3.0)
cat does this.  If I cat an nfs directory it exits after printing zero
bytes (no error message); it even exits with status 0.

I'll be glad to fix it - but I need source.  Not only do you not ship
source by default, you want us to pay (and pay lots!) for it.  And
we're not even for-profit.

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse at harvard.harvard.edu