Re: question for cp tools

[Jim Meyering]

address@hidden (Bob Proulx) wrote:
> Jim Meyering wrote:
>> I've noticed that my use of `source' below might be misunderstood.
>> Here's a snippet from the documentation that should help:
>>
>>      mv [OPTION]... SOURCE DEST
>>      mv [OPTION]... SOURCE... DIRECTORY
>
> I can see that you are emphasizing the difference between the set of
> source and the set of destination files and the rules applied to those
> two difference sets.  However, fundamentally why are they different?
> I don't think they should be treated differently.

People just `know' that preexisting destination files may
be modified or removed.  The manual says that, too :)
The manual doesn't warn about the possibility of `mv'
removing SOURCE files in some unusual cases, and doing
so would seem too much like breaking an implicit contract.

> Note that I have never heard discussion of this with 'cp' but only
> with 'mv'.  Fundamentally I think 'mv' and 'cp' are conceptually
> different.

True, but sometimes people perform a move-like operation
via commands like cp SOURCE... dest && ... && rm -rf SOURCE...,
so the same logic applies.

>> In general, you can add mv's --backup option:
>>
>>    mv --backup=numbered */*/foo ../ARCHIVE/
>
> So, why does --backup=numbered work but --backup=simple fail?

Because detecting when --backup=simple would be safe looked like it'd be
too much trouble to be worthwhile, and besides, adding code to do that
would impact the usual case by increasing the size of the F_triple struct.
Or we could add more code and a separate, much smaller, table just to
remember names of files that are overwritten two or more times -- but
that would be overkill, even if you ignored the complications of the
fourth backup type (`existing' can lead to simple or numbered backups)
and the fact that the new table would have to be initialized in every
caller of copy (mv, cp, install).