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