++ bugs mailling list On Mon 4 Jun, 2018, 3:59 AM Gunjan Gupta, 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, 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 >> >>