GNU bug report logs -
#31675
Existing directories and files permissions are not being kept intact
Previous Next
Reported by: Gunjan Gupta <viraniac <at> gmail.com>
Date: Fri, 1 Jun 2018 07:41:02 UTC
Severity: normal
Tags: notabug
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 03/06/18 15:30, Gunjan Gupta wrote:
> ++ bugs mailling list
>
> On Mon 4 Jun, 2018, 3:59 AM Gunjan Gupta, <viraniac <at> gmail.com> wrote:
>
>> No cpvdidnt created that directory. Directory was existing on the machine
>> before.
>>
>> It used to be fine before 8.26 version of coreutils and we use to supply
>> patches to our customer that use to use cp to copy files to the destination.
>>
>> Starting from 8.26, its broken. What will happen if we use the same
>> command to copy files to say /etc directory. I had one of our patch that
>> used to do that. I tried installing it on new system and whole system broke
>> because of this.
>>
>> Don't you think cp should preserve permissions for existing files and
>> directory? Using user's umask for new files sounds ok but why cp has to
>> change mode for existing files and directories?
>>
>> Is there a way I can tell cp to preserve destination permissions now?
>>
>> Thanks & Regards
>> Gunjan Gupta
>>
>> On Mon 4 Jun, 2018, 3:50 AM Pádraig Brady, <P <at> draigbrady.com> wrote:
>>
>>> tag 31675 notabug
>>> close 31675
>>> stop
>>>
>>> On 31/05/18 20:50, Gunjan Gupta wrote:
>>>> Hi,
>>>>
>>>> Suppose I have the following directory structure
>>>>
>>>> /
>>>> | - destination (mode=0755)
>>>> | - dir (mode=0755)
>>>> | - file.txt (mode=0644)
>>>> | - source
>>>> | - dir (mode=0755)
>>>> | - file.txt (mode=0644)
>>>>
>>>> My user has a umask of 0077. Now if I run the following cp command
>>>>
>>>> cp -aR --no-preserve=mode /source/* /destination
>>>>
>>>> I think the mode of destination/dir should stay as 0755 but it changes
>>> to
>>>> 0700. Is this expected?
>>>>
>>>> I am using coreutils 8.26-3 on Debian Stretch
>>>
>>> This is a little surprising as cp didn't create /destination/dir in this
>>> case.
>>> However if it did create that dir, then the mode would be expected.
>>> So cp is keeping the destination consistent whether it previously existed
>>> or not.
Actually looking more, this is a relatively recent change:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.19-145-g24ebca6
Also in retrospect, using --no-preserve=mode should
have no guarantees on the mode bits of the destination.
So it's probably best to leave existing mode bits in place.
Let me see if I can come up with a patch...
thanks,
Pádraig
This bug report was last modified 7 years and 44 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.