GNU bug report logs -
#50784
coreutils 9.0 sometimes gets spurious failures in chmod -R
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50784 in the body.
You can then email your comments to 50784 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#50784
; Package
coreutils
.
(Fri, 24 Sep 2021 18:23:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Daniel Schepler <dschepler <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Fri, 24 Sep 2021 18:23:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
After I upgraded my system (locally built) to coreutils 9.0, I noticed
that my lightly modified sbuild started getting build failures when it
tries to run "chmod -R g+w /<<BUILDDIR>>" (as root) in the chroot.
I'm not sure exactly what combination of files triggers the error, but
I'm able to reproduce it roughly as follows:
cd /tmp
tar -x -f .../coreutils-9.0.tar.xz
cd coreutils-9.0
mkdir obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu
../configure --prefix=/usr
make -j8
chmod -R u+w /tmp/coreutils-9.0/obj-x86_64-linux-gnu
echo $?
In the last chmod command, there are no failures reported; and even if
I run it under strace, I see no hints of any failed system calls other
than one in access("/etc/ld.so.preload", R_OK) at startup -- and
certainly no failures in the fchmodat() system calls. Yet the exit
code from the process is 1.
I wasn't seeing any such errors under sbuild using coreutils 8.32.
--
Daniel Schepler
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#50784
; Package
coreutils
.
(Fri, 24 Sep 2021 19:30:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 50784 <at> debbugs.gnu.org (full text, mbox):
On 24/09/2021 19:21, Daniel Schepler wrote:
> After I upgraded my system (locally built) to coreutils 9.0, I noticed
> that my lightly modified sbuild started getting build failures when it
> tries to run "chmod -R g+w /<<BUILDDIR>>" (as root) in the chroot.
> I'm not sure exactly what combination of files triggers the error, but
> I'm able to reproduce it roughly as follows:
>
> cd /tmp
> tar -x -f .../coreutils-9.0.tar.xz
> cd coreutils-9.0
> mkdir obj-x86_64-linux-gnu
> cd obj-x86_64-linux-gnu
> ../configure --prefix=/usr
> make -j8
> chmod -R u+w /tmp/coreutils-9.0/obj-x86_64-linux-gnu
> echo $?
>
> In the last chmod command, there are no failures reported; and even if
> I run it under strace, I see no hints of any failed system calls other
> than one in access("/etc/ld.so.preload", R_OK) at startup -- and
> certainly no failures in the fchmodat() system calls. Yet the exit
> code from the process is 1.
>
> I wasn't seeing any such errors under sbuild using coreutils 8.32.
Drats. I think it's determining ignoring symlinks as an error.
Could you try with the following untested diff:
diff --git a/src/chmod.c b/src/chmod.c
index 37b04f500..9ab60898d 100644
--- a/src/chmod.c
+++ b/src/chmod.c
@@ -322,6 +322,9 @@ process_file (FTS *fts, FTSENT *ent)
if ( ! recurse)
fts_set (fts, ent, FTS_SKIP);
+ if (ch.status == CH_NOT_APPLIED) /* For symlinks. */
+ ch.status = CH_NO_CHANGE_REQUESTED;
+
return CH_NO_CHANGE_REQUESTED <= ch.status;
}
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#50784
; Package
coreutils
.
(Fri, 24 Sep 2021 20:04:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 50784 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 24/09/2021 20:29, Pádraig Brady wrote:
> On 24/09/2021 19:21, Daniel Schepler wrote:
>> After I upgraded my system (locally built) to coreutils 9.0, I noticed
>> that my lightly modified sbuild started getting build failures when it
>> tries to run "chmod -R g+w /<<BUILDDIR>>" (as root) in the chroot.
>> I'm not sure exactly what combination of files triggers the error, but
>> I'm able to reproduce it roughly as follows:
>>
>> cd /tmp
>> tar -x -f .../coreutils-9.0.tar.xz
>> cd coreutils-9.0
>> mkdir obj-x86_64-linux-gnu
>> cd obj-x86_64-linux-gnu
>> ../configure --prefix=/usr
>> make -j8
>> chmod -R u+w /tmp/coreutils-9.0/obj-x86_64-linux-gnu
>> echo $?
>>
>> In the last chmod command, there are no failures reported; and even if
>> I run it under strace, I see no hints of any failed system calls other
>> than one in access("/etc/ld.so.preload", R_OK) at startup -- and
>> certainly no failures in the fchmodat() system calls. Yet the exit
>> code from the process is 1.
>>
>> I wasn't seeing any such errors under sbuild using coreutils 8.32.
>
> Drats. I think it's determining ignoring symlinks as an error.
> Could you try with the following untested diff:
>
> diff --git a/src/chmod.c b/src/chmod.c
> index 37b04f500..9ab60898d 100644
> --- a/src/chmod.c
> +++ b/src/chmod.c
> @@ -322,6 +322,9 @@ process_file (FTS *fts, FTSENT *ent)
> if ( ! recurse)
> fts_set (fts, ent, FTS_SKIP);
>
> + if (ch.status == CH_NOT_APPLIED) /* For symlinks. */
> + ch.status = CH_NO_CHANGE_REQUESTED;
> +
> return CH_NO_CHANGE_REQUESTED <= ch.status;
> }
Tested equivalent patch is attached.
[chmod-fix-symlink-exit.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#50784
; Package
coreutils
.
(Fri, 24 Sep 2021 21:44:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 50784 <at> debbugs.gnu.org (full text, mbox):
On Fri, Sep 24, 2021 at 1:02 PM Pádraig Brady <P <at> draigbrady.com> wrote:
> > Could you try with the following untested diff:
>
> Tested equivalent patch is attached.
Yes, with chmod-fix-symlink-exit.patch applied and the resulting
packages installed for testing, the issue does appear to be resolved.
--
Daniel Schepler
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#50784
; Package
coreutils
.
(Fri, 24 Sep 2021 22:38:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 50784 <at> debbugs.gnu.org (full text, mbox):
On 9/24/21 22:02, Pádraig Brady wrote:
> Tested equivalent patch is attached.
Nice small patch.
Maybe it's worth documenting in the enum where the "bad range" starts against which the
code later tests?
Furthermore, I think it's worth adding a NEWS entry and mentioning that this bug has been
introduced in v9.0, namely in v8.32-193-gbbb19b186.
Thanks & have a nice day,
Berny
Reply sent
to
Pádraig Brady <P <at> draigBrady.com>
:
You have taken responsibility.
(Fri, 24 Sep 2021 22:49:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Daniel Schepler <dschepler <at> gmail.com>
:
bug acknowledged by developer.
(Fri, 24 Sep 2021 22:49:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 50784-done <at> debbugs.gnu.org (full text, mbox):
On 24/09/2021 22:42, Daniel Schepler wrote:
> On Fri, Sep 24, 2021 at 1:02 PM Pádraig Brady <P <at> draigbrady.com> wrote:
>>> Could you try with the following untested diff:
>>
>> Tested equivalent patch is attached.
>
> Yes, with chmod-fix-symlink-exit.patch applied and the resulting
> packages installed for testing, the issue does appear to be resolved.
Thanks for testing.
Pushed (with NEWS update).
marking this as done.
thanks,
Pádraig
Forcibly Merged 50784 50791.
Request was from
Pádraig Brady <P <at> draigBrady.com>
to
control <at> debbugs.gnu.org
.
(Fri, 24 Sep 2021 22:51:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
50784 <at> debbugs.gnu.org and Daniel Schepler <dschepler <at> gmail.com>
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Sat, 15 Jan 2022 01:11:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 12 Feb 2022 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 72 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.