Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!think!ames!elroy!david
From: david@elroy.Jpl.Nasa.Gov (David Robinson)
Newsgroups: comp.unix.wizards
Subject: Re: directory copying with cp; broken?
Message-ID: <10148@elroy.Jpl.Nasa.Gov>
Date: 12 Oct 88 05:31:15 GMT
References: <40@ausonics.OZ> <30506@bbn.COM> <506@quintus.UUCP> <10073@yavin.uucp> <522@quintus.UUCP>
Organization: Image Analysis Systems Grp, JPL
Lines: 30

In article <522@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes:
> In article <10073@yavin.uucp> mike_s@sun.UUCP (Mike Sullivan) writes:
> >In article <506@quintus.UUCP> ok@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@csvax.caltech.edu     ARPA
				david@elroy.jpl.nasa.gov	  ARPA
				{cit-vax,ames}!elroy!david	  UUCP
Disclaimer: No one listens to me anyway!