bug#31675: Existing directories and files permissions are not being kept intact

[Gunjan Gupta]

++ bugs mailling list

On Mon 4 Jun, 2018, 3:59 AM Gunjan Gupta, <address@hidden> 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, <address@hidden> 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.
>>
>> cheers,
>> Pádraig
>>
>>