[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9170: [PATCH] cp "restores" permissions it never set
From: |
Jim Meyering |
Subject: |
bug#9170: [PATCH] cp "restores" permissions it never set |
Date: |
Tue, 26 Jul 2011 09:36:12 +0200 |
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