bug#8391: chmod setuid & setguid bits

On 03/31/2011 02:15 PM, Eric Blake wrote: > I also don't know how many of the implementations are technically right > - POSIX allows a wide range of acceptable behavior, but did require that > the particular behavior used be documented (not like anyone wants to > read documentation for multiple imp

bug#8391: chmod setuid & setguid bits

Hi No, 0755 is not explicit - it is ambiguous with people that are explicitly using printf %#3o to output a 3-digit octal string with leading 0 - I don't think we can change this. But my suggestion of 00755 _is_ explicit - after taking off the leading 00755 is working here. I can live with that

bug#8391: chmod setuid & setguid bits

On 03/31/2011 01:58 PM, Christian wrote: > Hi Paul, > > Am 31.03.2011 20:54, schrieb Paul Eggert: >> On 03/31/2011 11:25 AM, Christian wrote: >>> and using "0755" is explicit enough, isn't it ? >> Unfortunately it's not that simple, as having 0755 mean >> something different from 755 would violate

bug#8391: chmod setuid & setguid bits

Hi Paul, Am 31.03.2011 20:54, schrieb Paul Eggert: On 03/31/2011 11:25 AM, Christian wrote: and using "0755" is explicit enough, isn't it ? Unfortunately it's not that simple, as having 0755 mean something different from 755 would violate the principle of least surprise. Please see the thread

bug#8391: chmod setuid & setguid bits

On 03/31/2011 12:54 PM, Paul Eggert wrote: > On 03/31/2011 11:25 AM, Christian wrote: >> and using "0755" is explicit enough, isn't it ? > > Unfortunately it's not that simple, as having 0755 mean > something different from 755 would violate the principle > of least surprise. Please see the threa

bug#8391: chmod setuid & setguid bits

On 03/31/2011 11:25 AM, Christian wrote: > and using "0755" is explicit enough, isn't it ? Unfortunately it's not that simple, as having 0755 mean something different from 755 would violate the principle of least surprise. Please see the thread starting at

bug#8391: chmod setuid & setguid bits

On 03/31/2011 12:25 PM, Christian wrote: > IMHO > for removing s-gid-bit from > drwxr-sr-x 2 root root 48 2011-03-31 18:13 tmp/ > "u=rwx,g=rx-s,o=rx" == "0755" > > and using "0755" is explicit enough, isn't it ? No, because not everyone realizes that chmod takes octal automatically, and they mi

bug#8391: chmod setuid & setguid bits

Hi Eric, Am 31.03.2011 19:29, schrieb Eric Blake: On 03/31/2011 03:01 AM, Christian wrote: Why can I only use symbolic modes for clearing ? snip chmod(1) --- and you can set (but not clear) the bits with a numeric mode. snip chmod(1) --- isn't "chmod 0755 DIR" explicit enough ? Thank

bug#8374: cp -a [-l] sometimes does not preserve timestamps of symlinks

On 31/03/11 15:20, Eric Blake wrote: > Sounds to me like the gnulib fallback should be made smarter. Which > systems lack linkat() but have the capability to set timestamps? BSD? > But the original report was about opensuse, which is Linux based, and my > recollection is that Linux handles hardli

bug#8374: cp -a [-l] sometimes does not preserve timestamps of symlinks

On 29/03/11 14:46, Ruediger Meier wrote: > Hi, > > > I see you fixed that already for for cp -a > http://marc.info/?t=12489708961&r=1&w=2 > > But it does not together with option -link: > > cd /tmp/ > ln -s somewhere symlink > touch -h -t "19700101" symlink > cp -a symlink symlink-a >

bug#8375: cp -a [-l] sometimes does not preserve timestamps of symlinks

tags 8375 + notabug closing this cloned bug

bug#8374: cp -a [-l] sometimes does not preserve timestamps of symlinks

[adding bug-gnulib] On 03/31/2011 08:11 AM, Pádraig Brady wrote: >> So probably -al is broken since you fixed -a in 7.5. > > Hmm it looks now like we're creating symlinks (with wrong timestamps), > but in fact we should be creating hardlinks to symlinks. > > This seems to have been changed with: