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 <[email protected]> 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
