finding NFS dirs in csh?

Lindsay F. Marshall lindsay at cheviot.newcastle.ac.uk
Mon Dec 22 23:29:49 AEST 1986


In article <10398 at sun.uucp> guy at sun.uucp (Guy Harris) writes:
>When you read a directory entry, you want the i-number (and any other
>numbers in the directory entry) 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.  (Otherwise, it would
>*really* be non-transparent.)

Quite Right.

>As such, you must use a system call that
>knows you're trying to read directory entries, so that they can be put into
>a standard form at the sending site and put into the native form at the
>receiving site.

Also quite right - the "read" system call is exactly that kind of system call.
The Newcastle Connection supports these semantics for read and will cope with
V7 style access to directories on remote systems of many kinds. Yes there are
some things that cant be done - long file names, 32 bit i numbers, but in
general these dont cause a problem - most people just want to be able to say
"ls /remote/dir" and this works fine. Oh yes, the getdirentries system
call is supported as well for those who like need that kinf of thing.


>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.  In
>fact, if the two machines are, say, a Sun and a VAX, it would pretty much be
>*guaranteed* to get wrong answers!

Quite wrong - this type of thing is very easy to do.

	Lindsay
------------------------------------------------------------------------------
Lindsay F. Marshall, Computing Lab., U of Newcastle upon Tyne, Tyne & Wear, UK
  ARPA  : lindsay%cheviot.newcastle.ac.uk at ucl-cs.arpa
  JANET : lindsay at uk.ac.newcastle.cheviot
  UUCP  : <UK>!ukc!cheviot!lindsay
-------------------------------------------------------------------------------



More information about the Comp.unix.questions mailing list