bug#9170: [PATCH] cp "restores" permissions it never set

[Jim Meyering]

Paul Eggert wrote:
> On 07/26/11 00:08, Jim Meyering wrote:
>
>> Do you feel like tracking down the point at which
>> the bug was introduced to mention it in NEWS?
>
> To be honest, I prefer thinking about the future
> to worrying about the past.  Could we just omit
> that part of the announcement?  If someone cares
> about the past, they can look it up.

It's useful for people maintaining older systems, so I looked
it up.  I confirmed it was introduced between 6.7 and 6.8.
Of the six copy.c-affecting commits in that range, only
b28a8851ed22dbf0cd123974a0c97ae0b82bec2b touches permissions.

I'll push this shortly:

>From b2bb19b4b32506debf65f03c8e44b66374550597 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Tue, 26 Jul 2011 09:24:31 +0200
Subject: [PATCH] doc: mention cp's dir-permissions fix

* NEWS (Bug fixes): Mention yesterday's dir-permissions fix.
---
 NEWS |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index a4e7e9e..291ce13 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,9 @@ GNU coreutils NEWS                                    -*- 
outline -*-
   I.E. for skipped files, the original ownership is output, not the new one.
   [bug introduced in sh-utils-2.0g]

+  cp -r could mistakenly change the permissions of an existing destination
+  directory.  [bug introduced in coreutils-6.8]
+
   cp -u -p would fail to preserve one hard link for each up-to-date copy
   of a src-hard-linked name in the destination tree.  I.e., if s/a and s/b
   are hard-linked and dst/s/a is up to date, "cp -up s dst" would copy s/b
--
1.7.6.609.gbf6a9