[comp.bugs.4bsd] directory copying with cp; broken?

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