Re: [PATCH] tests: copy.c destination permissions lost when backup specified

[Jim Meyering]

Sami Kerola wrote:
> On Mon, Mar 30, 2009 at 13:43, Jim Meyering <address@hidden> wrote:
>> Sami Kerola wrote:
>>> Either this is bug or an unintuitive feature.
>>>
>>> address@hidden ~/foo touch src dest
>>> address@hidden ~/foo chmod g-rwx src
>>> address@hidden ~/foo chmod g+rwx dest
>>> address@hidden ~/foo ls -l
>>> total 0
>>> -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest
>>> -rw----r-- 1 sake sake 0 2009-03-30 13:16 src
>>> address@hidden ~/foo cp --force --backup=t src dest
>>> address@hidden ~/foo ls -l
>>> total 0
>>> -rw----r-- 1 sake sake 0 2009-03-30 13:16 dest
>>> -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest.~1~
>>> -rw----r-- 1 sake sake 0 2009-03-30 13:16 src
>>>
>>> In case this is bug the patch is good. In case of feature it should be
>>> modified to make sure that permissions are different.
>>
>> It's a feature.
>> With --backup, an existing destination is first moved aside (renamed),
>> and thus the backup retains all attributes.  That's the idea of making a
>> backup, after all: preserve as much initial state as possible.
>
> I give great value for backups, but still I would like to see new and
> old destination files to have same permissions. Of course when
> --preserve is specified expectation is changed; source permission
> should appear for the new file.
>
> Am I only one thinking this way?

Perhaps.
In any case, this behavior dates back to the invention of the --backup
option over 17 years ago.

Sorry, but I see no reason to change it.