bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Rich Felker
On Wed, Jan 22, 2020 at 01:55:57PM -0800, Paul Eggert wrote: > On 1/22/20 7:08 AM, Florian Weimer wrote: > >I think you misread what I wrote: lchmod*always* returns ENOSYS. Even > >if the file is not a symbolic link. Likewise, fchmodat with > >AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP. > >

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Paul Eggert
On 1/22/20 7:08 AM, Florian Weimer wrote: I think you misread what I wrote: lchmod*always* returns ENOSYS. Even if the file is not a symbolic link. Likewise, fchmodat with AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP. That's too bad, because coreutils (and many other applications, I

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Florian Weimer
* Rich Felker: > On Wed, Jan 22, 2020 at 09:48:14PM +0100, Florian Weimer wrote: >> * Rich Felker: >> >> >> Hmm. The way I read the musl code, the O_PATH descriptor already >> >> exists. At this point, you can just chmod the O_PATH descriptor, and >> >> have the kernel report EOPNOTSUPP if the

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Florian Weimer
* Rich Felker: >> Hmm. The way I read the musl code, the O_PATH descriptor already >> exists. At this point, you can just chmod the O_PATH descriptor, and >> have the kernel report EOPNOTSUPP if the file system does not support >> that. > > Oh, you mean the second one after it's already open?

bug#39135: Globbing with numbers does not allow me to specify order

2020-01-22 Thread Bob Proulx
Antti Savolainen wrote: > When doing a shortcut to unmount in a specific order, I am unable to > specify order with angle brackets. For example using 'umount /dev/sda[132]' > will result in the system unmounting them in numerological order. First 1 > then 2 and finally 3. What I need it to do is

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Rich Felker
On Wed, Jan 22, 2020 at 05:19:05PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: > >> >> * Rich Felker: > >> >> > >> >> > On Wed,

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Florian Weimer
* Rich Felker: > On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote: >> * Rich Felker: >> >> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: >> >> * Rich Felker: >> >> >> >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: >> >> >> * Rich Felker:

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Rich Felker
On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: > >> >> * Rich Felker: > >> >> > >> >> >

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Rich Felker
On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: > * Rich Felker: > > > coreutils should be opting to use the system-provided lchmod, which is > > safe, and correctly handling error returns (silently treating > > EOPNOTSUPP as success) rather than as hard errors. > > glibc's

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Rich Felker
On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: > >> * Rich Felker: > >> > >> > coreutils should be opting to use the system-provided lchmod, which is > >> > safe, and correctly handling error

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Florian Weimer
* Rich Felker: > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote: >> * Rich Felker: >> >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: >> >> * Rich Felker: >> >> >> >> > coreutils should be opting to use the system-provided lchmod, which is >> >> > safe, and

bug#39237: coreutils cp mishandles error return from lchmod

2020-01-22 Thread Rich Felker
cp (and perhaps other utilities) are treating EOPNOTSUPP from lchmod as a hard error rather than an indication that the system does not support modes for symlinks. This recently came up on https://bugs.gentoo.org/687236#c17 where users are claiming recent changes to gnulib made the problem go

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Florian Weimer
* Rich Felker: > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote: >> * Rich Felker: >> >> > coreutils should be opting to use the system-provided lchmod, which is >> > safe, and correctly handling error returns (silently treating >> > EOPNOTSUPP as success) rather than as hard

bug#39236: [musl] coreutils cp mishandles error return from lchmod

2020-01-22 Thread Florian Weimer
* Rich Felker: > coreutils should be opting to use the system-provided lchmod, which is > safe, and correctly handling error returns (silently treating > EOPNOTSUPP as success) rather than as hard errors. glibc's lchmod always returns ENOSYS (except on Hurd). I don't know how lchmod is used in