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

[Sami Kerola]

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?

-- 
   Sami Kerola
   http://www.iki.fi/kerolasa/