greyham@ausonics.OZ (Greyham Stoney) (09/16/88)
No doubt people have noticed this before, but to my way of thinking [and this may well be the problem :-] cp on our BSD 4.2 system seems to be braindamaged. When both the source and destination are directories, and the -r option is not specified, the destination directory is left with a *file* by the name of the source directory. Much the same as if cp sourcedir destdir was really doing: cat sourcedir > destdir/sourcedir I would have though cp intelligent enough to realise that source and dest were directorys, and either do what the -r option does (so why do we need it?) or just reject the copy. (depending on how you view these types of things) Which ever solution, surely changing a directory into a regular file is a bit inconsistent?. greyham@ausonics.oz -- # Greyham Stoney: (disclaimer not necessary: I'm obviously irresponsible) # greyham@ausonics.oz - Ausonics Pty Ltd, Lane Cove. | greyham@utscsd.oz - # ^^^^^^^ (Official Sponsor of this message.) | Uni of Technology, Syd. # [.signature changed to celebrate NEW LOGNAME!! ] | Good Time City!!!
henry@utzoo.uucp (Henry Spencer) (09/21/88)
We long ago changed cp to reject an attempt to copy a directory. We've never been sorry. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.ARPA (Doug Gwyn ) (09/21/88)
In article <35@ausonics.OZ> greyham@ausonics.OZ (Greyham Stoney) writes: >... surely changing a directory into a regular file is a bit inconsistent?. "cp" is not changing anything; it's making a copy of the contents of a file. It wouldn't be safe for that to be turned into an actual directory since at least the "." entry in it would be incorrect.
greyham@ausonics.OZ (Greyham Stoney) (09/28/88)
in article <8540@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) says: > > In article <35@ausonics.OZ> greyham@ausonics.OZ (Greyham Stoney) writes: >>... surely changing a directory into a regular file is a bit inconsistent?. > > "cp" is not changing anything; it's making a copy of the contents of a > file. It wouldn't be safe for that to be turned into an actual > directory since at least the "." entry in it would be incorrect. Minor semantic point. Come on, you know what I was getting at. No, I wasn't proposing it should create a directory, but rather that it made more sense to reject the copy (or just copy the directory contents and do away with the -r flag). Just depends on how you look at it I guess. Greyham -- # Greyham Stoney: (disclaimer not necessary: I'm obviously irresponsible) # greyham@ausonics.oz - Ausonics Pty Ltd, Lane Cove. | greyham@utscsd.oz - # ^^^^^^^ (Official Sponsor of this message.) | Uni of Technology, Syd. # [.signature changed to celebrate NEW LOGNAME!! ] | (what can I say...)
mesard@bbn.com (Wayne Mesard) (10/05/88)
Note Followup-To. From article <40@ausonics.OZ>, by greyham@ausonics.OZ (Greyham Stoney): > in article <8540@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) says: >> "cp" is not changing anything; it's making a copy of the contents of a >> file. It wouldn't be safe for that to be turned into an actual >> directory since at least the "." entry in it would be incorrect. > > Minor semantic point. Come on, you know what I was getting at. No, I wasn't > proposing it should create a directory, but rather that it made more sense to > reject the copy (or just copy the directory contents and do away with the -r > flag). Just depends on how you look at it I guess. > Greyham Indeed. And more generally, a consistent way of handling directories (i.e. directory files) needs to be established. In SunOS 3.4: cp <dir> <fn> ==> "cp: <dir>: Is a directory (not copied). head, tail, cat <dir> ==> {works} more <dir> ==> "*** <dir>: directory ***" My preference is for cp to do the right thing (i.e, nix the -r flag) and for cat, head and tail (and any other file display* programs) to behave as more(1) does, with the addition of a new option to cat(1) to explicitly tell it to treat a directory as an ordinary file. But that's just one opinion. * It would be silly to remove functionality from file _processing_ programs such as wc. -- void *Wayne_Mesard(); MESARD@BBN.COM BBN, Cambridge, MA
ok@quintus.uucp (Richard A. O'Keefe) (10/06/88)
In article <30506@bbn.COM> mesard@bbn.com (Wayne Mesard) writes: >Indeed. And more generally, a consistent way of handling directories >(i.e. directory files) needs to be established. In SunOS 3.4: > head, tail, cat <dir> ==> {works} Are you sure about that? In both SunOS 3.2 and SunOS 4.0, % cat . cat: read error: Is a directory In straight 4.2BSD, if you read a directory, you get the file names &c, but in SunOS 3.x and 4.x, a directory always appears to be empty. So "wc $Directory" in SunOS will always print "0 0 0".
mike_s@yavin.uucp (Mike Sullivan) (10/08/88)
In article <506@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <30506@bbn.COM> mesard@bbn.com (Wayne Mesard) writes: >>Indeed. And more generally, a consistent way of handling directories >>(i.e. directory files) needs to be established. In SunOS 3.4: >> head, tail, cat <dir> ==> {works} > >Are you sure about that? In both SunOS 3.2 and SunOS 4.0, > % cat . > cat: read error: Is a directory >In straight 4.2BSD, if you read a directory, you get the file names &c, >but in SunOS 3.x and 4.x, a directory always appears to be empty. So >"wc $Directory" in SunOS will always print "0 0 0". 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, printing "1 7 1024" (for a 2 block directory). Both also work under 3.5. There is a portable directory interface, and you are not supposed to be able to directly open directories (great sentence), but apparently you still can. Mike sun!yavin!mike_s
mike_s@yavin.uucp (Mike Sullivan) (10/08/88)
By the way, I just saw the message that said NFS was responsible for allowing you to 'cat .', but the '.' I was cat'ing is not NFS mounted. It is on my drive sitting next to me, mounted as type 4.2. Mike sun!yavin!mike_s
greyham@ausonics.OZ (Greyham Stoney) (10/11/88)
in article <30506@bbn.COM>, mesard@bbn.com (Wayne Mesard) says:
] From article <40@ausonics.OZ>, by greyham@ausonics.OZ (Greyham Stoney):
]> in article <8540@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) says:
]>> [stuff about what I (Greyham) said]
]> [pretty silly reply by me (Greyham)]
] [with which Wayne agreed; and I (Greyham) agree too, but then he said....]
]
] * It would be silly to remove functionality from file _processing_
] programs such as wc.
Sorry.... I must misunderstand you. You aren't suggesting using wc on a
directory are you? It's got inode numbers and stuff in there; you won't get the
right answer. (whatever you percieve the "right" answer to be)
Grey.
--
# Greyham Stoney: (disclaimer not necessary: I'm obviously irresponsible)
# greyham@ausonics.oz - Ausonics Pty Ltd, Lane Cove. (* Official Sponsor *)ok@quintus.uucp (Richard A. O'Keefe) (10/12/88)
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.
david@elroy.Jpl.Nasa.Gov (David Robinson) (10/12/88)
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!