Sami Kerola wrote: > On Mon, Mar 30, 2009 at 13:43, Jim Meyering <j...@meyering.net> wrote: >> Sami Kerola wrote: >>> Either this is bug or an unintuitive feature. >>> >>> s...@lelux ~/foo touch src dest >>> s...@lelux ~/foo chmod g-rwx src >>> s...@lelux ~/foo chmod g+rwx dest >>> s...@lelux ~/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 >>> s...@lelux ~/foo cp --force --backup=t src dest >>> s...@lelux ~/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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
