directory copying with cp; broken?
David Robinson
david at elroy.Jpl.Nasa.Gov
Wed Oct 12 15:31:15 AEST 1988
In article <522 at quintus.UUCP>, ok at quintus.uucp (Richard A. O'Keefe) writes:
> In article <10073 at yavin.uucp> mike_s at sun.UUCP (Mike Sullivan) writes:
> >In article <506 at quintus.UUCP> ok at quintus.UUCP I wrote:
> >>Are you sure about that? In both SunOS 3.2 and SunOS 4.0,
> >> % cat .
> >> cat: read error: Is a directory
> >I am running SunOS 4.0, and if I 'cat .' I get the contents of the
> >directory (file names, etc.), not a read error. "wc ." also works.
> I did actually _test_ my statement, but it never occurred to me to try
> it on a file server. Apparently directories in an "nfs"-mounted file
> system look empty, but directories in a "4.2"-mounted file system can
> still be read.
This is an interesting conflict between SYSV semantics and BSD semantics,
the former requiring directories to be read the other strongly discouraging
it. One NFS vendor (pyramid?) had a dual universe Unix and had an
interesting solution to the problem. In the BSD universe they simply
mapped the directory(3) calls into NFS readdir calls but in the ATT
universe they still allowed directories to be read. Since NFS servers
explicitly refuse a read operation on a directory they faked it by
having the client do a number of readdir calls and building on the
client a "copy" of the directory and causing read calls on directories
to return back this "copy". Pretty good I thought.
--
David Robinson elroy!david at csvax.caltech.edu ARPA
david at elroy.jpl.nasa.gov ARPA
{cit-vax,ames}!elroy!david UUCP
Disclaimer: No one listens to me anyway!
More information about the Comp.unix.wizards
mailing list