On 03/06/18 15:30, Gunjan Gupta wrote: > ++ bugs mailling list > > On Mon 4 Jun, 2018, 3:59 AM Gunjan Gupta, <[email protected]> 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, <[email protected]> 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
