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
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