GNU bug report logs - #50784
coreutils 9.0 sometimes gets spurious failures in chmod -R

Previous Next

Package: coreutils;

Reported by: Daniel Schepler <dschepler <at> gmail.com>

Date: Fri, 24 Sep 2021 18:23:01 UTC

Severity: normal

Merged with 50791, 53262

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Daniel Schepler <dschepler <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: coreutils 9.0 sometimes gets spurious failures in chmod -R
Date: Fri, 24 Sep 2021 11:21:40 -0700
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):

From: Pádraig Brady <P <at> draigBrady.com>
To: Daniel Schepler <dschepler <at> gmail.com>, 50784 <at> debbugs.gnu.org
Subject: Re: bug#50784: coreutils 9.0 sometimes gets spurious failures in
 chmod -R
Date: Fri, 24 Sep 2021 20:29:03 +0100
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):

From: Pádraig Brady <P <at> draigBrady.com>
To: Daniel Schepler <dschepler <at> gmail.com>, 50784 <at> debbugs.gnu.org
Subject: Re: bug#50784: coreutils 9.0 sometimes gets spurious failures in
 chmod -R
Date: Fri, 24 Sep 2021 21:02:56 +0100
[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):

From: Daniel Schepler <dschepler <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 50784 <at> debbugs.gnu.org
Subject: Re: bug#50784: coreutils 9.0 sometimes gets spurious failures in
 chmod -R
Date: Fri, 24 Sep 2021 14:42:51 -0700
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):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Daniel Schepler <dschepler <at> gmail.com>, 50784 <at> debbugs.gnu.org
Subject: Re: bug#50784: coreutils 9.0 sometimes gets spurious failures in
 chmod -R
Date: Sat, 25 Sep 2021 00:37:31 +0200
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):

From: Pádraig Brady <P <at> draigBrady.com>
To: Daniel Schepler <dschepler <at> gmail.com>
Cc: 50784-done <at> debbugs.gnu.org
Subject: Re: bug#50784: coreutils 9.0 sometimes gets spurious failures in
 chmod -R
Date: Fri, 24 Sep 2021 23:48:43 +0100
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.

Merged 50784 50791 53262. 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 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.