bug#15727: Bug: cp <-a|-archive> (w/<-f|--remove-destination>) breaks if one of files is a dir and other not

[Linda Walsh]

> So why not enhance rsync regarding performance?
----
It's designed for slow, remote copies.  It special-cases local copies, but
uses much of the of the old code.  It also follows it's
manpage.  It also does id translation and storage of ACL's and
Xattrs on file systems that don't support it.  It has a complete
different set of requirements.

cp was designed for locally mounted file systems.  Having
cp really be able to do "updates" with -u and really treat
destinations as files (-T) and really remove destinations
before attempting a copy, seems much more reasonable in line
with what cp should do.


> >   For that matter, 'cp' could _relearn_ a thing
> > or two from 'dd' when it comes to speed.
>
> IMO no: this would add further bloat to the sources
> which in turn is harder to maintain.  Ever looked at
> copy.c, e.g. at copy_internal()?
---
Yes.  It's grown considerably in the past few years.  But the main
thing it could relearn from 'dd' is using larger buffer sizes.

It's only half the speed of DD, so it's not like it's *that* slow.
(vs. rsync, being ~32x slower for a LAN mounted file to a local copy).

Where as cp from ~5 years ago used to be about 80% the speed of 'dd'.

So cp's speed has dropped by ~33%...

That's what I meant by "relearn" a thing to two from dd.

(likely in regards to buffer size, where on dd I'll specify 16M for
over LAN copies.

> > fast as 'dd', but now that often doesn't seem to be the case.
>
> hmm, well, could it be that this is because many features have
> been added over the years? ...
----
possibly -- but if it used larger buffer sizes, that problem would
mostly go away.  Like I said -- it's not that much worse that 'dd'.



> I think rm is simply not the right tool for such kind
> of synchronization.
----
synchronization implies deleting files on target that don't exist
on source.  That's not updating or "treating remote as file" for
purposes of update (-T)


You need to make the docs much more clear about "cp"s limitations.

update isn't eally update, and -T is certainly wrong at the very
least.  If you feel you'd rather document cp's limitations,
that's fine...

cp is a great tool, don't get me wrong!  But when it added update
and -T, --remove-destination, it started inferring or promising
more than you were willing to deliver.  That should be documented.

To be honest, I missed the 'file' bit in --remove-destination and
focused on how it was different from -f in removing the destination
before the copy (manpage says to contrast w/-f)...

That still doesn't let it off the hook w/regards to "-T" where it
doesn't treat the destination as a file and remove it first.