GNU bug report logs - #12494
0 exit status even when chmod fails

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 12494 in the body.
You can then email your comments to 12494 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Georgiy Treyvus <georgiytreyvus <at> riseup.net>
To: bug-coreutils <at> gnu.org
Subject: 0 exit status even when chmod fails
Date: Sun, 23 Sep 2012 01:59:37 -0400

I was helping a newbie friend of mine try to get some games of his 
running. It quickly became apparent that the program didn't have execute 
permission. I thought a simple chmod 755 would do the job. Apparently 
not. We try again and check afterwards. Still won't execute. We do it 
again. We check the exit status. Executable? No. Exit status? 0.  
Compiled for Linux and not say Winblowse? Yes. What the bloody hell was 
going on here?

There were a few more vain tries. We tried following through on other 
crackpot ideas of mine to no avail. Then came ripping out all the hair 
on my head and other places best left to the imagination, waiting for it 
to regrow and doing it all over again.

Finally I had him show me the mount options of the relevant partitions. 
Many I recognized. Some I did not. I started researching those I did 
not. It turns out they had nothing to do with the problem at hand. But I 
did inadvertently find out what went wrong as a consolation prize. 
Apparently chmod doesn't work on vfat or ntfs. Ultimately it was 
understandable as the permission schemes are radically different and now 
that I thought about it that'd be quite a feat to be able to translate 
between them in any meaningful way.

Chmod doesn't work on vfat? Fair enough. But it shouldn't be returning a 
0 exit code for failure. Generally when chmod fails or can't do 
something it returns an non-zero exit code. I see no reason that there 
should be an exception just because it's incompatible with vfat. This 
can be very problematic in scripts that rely on knowing the success of 
the command/exit code. Please look into this.

Message #8 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Georgiy Treyvus <georgiytreyvus <at> riseup.net>
Cc: 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: 0 exit status even when chmod fails
Date: Sun, 23 Sep 2012 23:29:13 -0700

On 09/22/2012 10:59 PM, Georgiy Treyvus wrote:
> it shouldn't be returning a 0 exit code for failure

Unless I'm missing something, I'd guess that
the chmod command is just executing the chmod
system call, which means that if it is reporting
success that one should be looking at how the
system call is implemented, not at how the
chmod command is implemented.

You can test this theory by running it under
strace.  E.g.:

  strace -o chmod.tr chmod 755 file

and look at what 'chmod.tr' says about when the
chmod system call is being executed.

Message #11 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: georgiytreyvus <at> riseup.net (Georgiy Treyvus)
Cc: 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: 0 exit status even when chmod fails
Date: Mon, 24 Sep 2012 01:37:16 -0500 (GMT+5)

Georgiy Treyvus writes:
> 
> Finally I had him show me the mount options of the relevant partitions. 
> Many I recognized. Some I did not. I started researching those I did 

Did you notice this one?:

Mount options for fat
       (Note:  fat  is	not  a	separate  filesystem, but a common part of the
       msdos, umsdos and vfat filesystems.)

[...]
       quiet  Turn on the quiet flag.  Attempts to chown or chmod files do not
	      return errors, although they fail. Use with caution!

If you're getting the quiet behavior without the quiet mount option, I'd say
that's a kernel bug.

-- 
Alan Curry

Message #14 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: Sven Joachim <svenjoac <at> gmx.de>
To: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
Cc: Georgiy Treyvus <georgiytreyvus <at> riseup.net>, 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: 0 exit status even when chmod fails
Date: Mon, 24 Sep 2012 21:21:18 +0200

On 2012-09-24 08:37 +0200, Alan Curry wrote:

> Georgiy Treyvus writes:
>> 
>> Finally I had him show me the mount options of the relevant partitions. 
>> Many I recognized. Some I did not. I started researching those I did 
>
> Did you notice this one?:
>
> Mount options for fat
>        (Note:  fat  is	not  a	separate  filesystem, but a common part of the
>        msdos, umsdos and vfat filesystems.)
>
> [...]
>        quiet  Turn on the quiet flag.  Attempts to chown or chmod files do not
> 	      return errors, although they fail. Use with caution!
>
> If you're getting the quiet behavior without the quiet mount option, I'd say
> that's a kernel bug.

Actually, it's the default unless you're using Linux 2.6.25.  This
kernel reported an error to the caller, but since that broke rsync[1,2],
2.6.26 reverted to the previous behavior of silently ignoring chmod
attempts which do not work on FAT filesystems[3].

This bug report should probably be closed.

Cheers,
       Sven


1. https://bugzilla.redhat.com/show_bug.cgi?id=449080
2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495594
3. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2d518f84e5ecd1d71df0e6ac5176d212f68c27ce

Message #17 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: svenjoac <at> gmx.de (Sven Joachim)
Cc: 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: 0 exit status even when chmod fails
Date: Mon, 24 Sep 2012 14:25:14 -0500 (GMT+5)

Sven Joachim writes:
> 
> On 2012-09-24 08:37 +0200, Alan Curry wrote:
> 
> > Georgiy Treyvus writes:
> >> 
> >> Finally I had him show me the mount options of the relevant partitions. 
> >> Many I recognized. Some I did not. I started researching those I did 
> >
> > Did you notice this one?:
> >
> > Mount options for fat
> >        (Note:  fat  is	not  a	separate  filesystem, but a common part of the
> >        msdos, umsdos and vfat filesystems.)
> >
> > [...]
> >        quiet  Turn on the quiet flag.  Attempts to chown or chmod files do not
> > 	      return errors, although they fail. Use with caution!
> >
> > If you're getting the quiet behavior without the quiet mount option, I'd say
> > that's a kernel bug.
> 
> Actually, it's the default unless you're using Linux 2.6.25.  This
> kernel reported an error to the caller, but since that broke rsync[1,2],
> 2.6.26 reverted to the previous behavior of silently ignoring chmod
> attempts which do not work on FAT filesystems[3].
> 
> This bug report should probably be closed.

If the mount man page disagrees with the kernel, it's still a bug in the man
page at least.

(Also, the rest of the world needs to work around extra stupidity because of
rsync?)

-- 
Alan Curry

Message #20 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: Sven Joachim <svenjoac <at> gmx.de>
To: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
Cc: 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: 0 exit status even when chmod fails
Date: Mon, 24 Sep 2012 22:35:27 +0200

On 2012-09-24 21:25 +0200, Alan Curry wrote:

> If the mount man page disagrees with the kernel, it's still a bug in the man
> page at least.

Possibly, but the mount manpage is not part of coreutils.

> (Also, the rest of the world needs to work around extra stupidity because of
> rsync?)

No, all stupidity here belongs to the FAT filesystems.  And the kernel
devs thankfully have a strict policy of not breaking userspace, so it's
unlikely that the behavior of chmod(2) will ever be changed; in any case
there's nothing coreutils can do.

Regards,
        Sven

Message #25 received at 12494-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Sven Joachim <svenjoac <at> gmx.de>
Cc: 12494-done <at> debbugs.gnu.org, Alan Curry <pacman-cu <at> kosh.dhis.org>
Subject: Re: bug#12494: 0 exit status even when chmod fails
Date: Tue, 25 Sep 2012 08:57:41 +0200

Sven Joachim wrote:

> On 2012-09-24 21:25 +0200, Alan Curry wrote:
>
>> If the mount man page disagrees with the kernel, it's still a bug in the man
>> page at least.
>
> Possibly, but the mount manpage is not part of coreutils.
>
>> (Also, the rest of the world needs to work around extra stupidity because of
>> rsync?)
>
> No, all stupidity here belongs to the FAT filesystems.  And the kernel
> devs thankfully have a strict policy of not breaking userspace, so it's
> unlikely that the behavior of chmod(2) will ever be changed; in any case
> there's nothing coreutils can do.

Thanks for explaining.  I've closed this bug.

Message #28 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: Georgiy Treyvus <georgiytreyvus <at> riseup.net>
To: 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod
	fails)
Date: Tue, 25 Sep 2012 13:56:22 -0400

[Message part 1 (text/plain, inline)]

On 9/25/12 3:00 AM, GNU bug Tracking System wrote:
> Your bug report
>
> #12494: 0 exit status even when chmod fails
>
> which was filed against the coreutils package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to12494 <at> debbugs.gnu.org.
>
Wait. Before you folks put the final nail in the coffin I have three 
points/questions:

1. The prototype of the chmod system call is:

*int chmod(const char **/path/*, mode_t*/mode/*)*

On success it returns 0 on failure it returns -1.

Now why on earth would this require a change in userspace? Any user that wants to use it can still invoke chmod() in exactly the same way without a problem.

Correcting chmod()'s behavior in the back section really shouldn't change the API or anything for the regular uses cases where chmod() is used on sane filesystems.

As for insane filesystems like vfat(and possibly ntfs though I'm not the surest as apparently I once read somewhere it has some sort of POSIX compatibility mode)
I think users will appreciate at the least a nonzero exit code.

Some sort of message written to stderr clarifying the reason for the exit status would probably also be appreciated.

How difficult would it be to have chmod() modified to check "is this shit vfat?" and return -1 like for any other error if it is?

How does this even consitute a change in the API/userspace as opposed to a bug in need of fixing?

2. Since this appears like a kernel issue obviously I'll have to take it up with them. I'm not that familiar(OK more like totally ignorant)
with the inner workings of the kernel nor it's development process and am kind of confused with regards to exactly who I would have to take this up with.
I heard also that they're very tough to deal with at times so any advice regarding how to approach them would be heavily appreciated.

3. Say things don't work out in talking with the kernel devs. What I think may(this being the key word here) be a plausible workaround is if you guys could somehow test even without relying
on chmod() what kind of filesystem are we dealing with. In that case if fat16/32, vfat (or ntfs possibly) comes up since it can't be done you return a nonzero value and
spout some sort of error message. Otherwise call chmod() have it finish off the job just like before. How likely would an approach like this be to work? What are to pros and cons?

Thanks!

[Message part 2 (text/html, inline)]

Message #31 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: Georgiy Treyvus <georgiytreyvus <at> riseup.net>
To: 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod
	fails)
Date: Tue, 25 Sep 2012 14:02:25 -0400

On 9/25/12 1:56 PM, Georgiy Treyvus wrote:
> On 9/25/12 3:00 AM, GNU bug Tracking System wrote:
>> Your bug report
>>
>> #12494: 0 exit status even when chmod fails
>>
>> which was filed against the coreutils package, has been closed.
>>
>> The explanation is attached below, along with your original report.
>> If you require more details, please reply to12494 <at> debbugs.gnu.org.
>>
> Wait. Before you folks put the final nail in the coffin I have three 
> points/questions:
>
> 1. The prototype of the chmod system call is:
>
> *int chmod(const char **/path/*, mode_t*/mode/*)*
>
> On success it returns 0 on failure it returns -1.
>
> Now why on earth would this require a change in userspace? Any user 
> that wants to use it can still invoke chmod() in exactly the same way 
> without a problem.
>
> Correcting chmod()'s behavior in the back section really shouldn't 
> change the API or anything for the regular uses cases where chmod() is 
> used on sane filesystems.
>
> As for insane filesystems like vfat(and possibly ntfs though I'm not 
> the surest as apparently I once read somewhere it has some sort of 
> POSIX compatibility mode)
> I think users will appreciate at the least a nonzero exit code.
>
> Some sort of message written to stderr clarifying the reason for the 
> exit status would probably also be appreciated.
>
> How difficult would it be to have chmod() modified to check "is this 
> shit vfat?" and return -1 like for any other error if it is?
>
> How does this even consitute a change in the API/userspace as opposed 
> to a bug in need of fixing?
>
> 2. Since this appears like a kernel issue obviously I'll have to take 
> it up with them. I'm not that familiar(OK more like totally ignorant)
> with the inner workings of the kernel nor it's development process and 
> am kind of confused with regards to exactly who I would have to take 
> this up with.
> I heard also that they're very tough to deal with at times so any 
> advice regarding how to approach them would be heavily appreciated.
>
> 3. Say things don't work out in talking with the kernel devs. What I 
> think may(this being the key word here) be a plausible workaround is 
> if you guys could somehow test even without relying
> on chmod() what kind of filesystem are we dealing with. In that case 
> if fat16/32, vfat (or ntfs possibly) comes up since it can't be done 
> you return a nonzero value and
> spout some sort of error message. Otherwise call chmod() have it 
> finish off the job just like before. How likely would an approach like 
> this be to work? What are to pros and cons?
>
> Thanks!
>
>
>
WTF why did the chmod() prototype get misformatted? Fucking email :(. 
Anyway I meant to write:
int chmod(const char * path,mode_t mode)

Message #34 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Georgiy Treyvus <georgiytreyvus <at> riseup.net>
Cc: 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod
	fails)
Date: Tue, 25 Sep 2012 14:47:34 -0600

[Message part 1 (text/plain, inline)]

On 09/25/2012 12:02 PM, Georgiy Treyvus wrote:
> On 9/25/12 1:56 PM, Georgiy Treyvus wrote:
>> On 9/25/12 3:00 AM, GNU bug Tracking System wrote:
>>> Your bug report
>>>
>>> #12494: 0 exit status even when chmod fails
>>>
>>> which was filed against the coreutils package, has been closed.
>>>
>>> The explanation is attached below, along with your original report.
>>> If you require more details, please reply to12494 <at> debbugs.gnu.org.
>>>
>> Wait. Before you folks put the final nail in the coffin I have three
>> points/questions:
>>
>> 1. The prototype of the chmod system call is:
>>
>> *int chmod(const char **/path/*, mode_t*/mode/*)*
>>
>> On success it returns 0 on failure it returns -1.
>>
>> Now why on earth would this require a change in userspace? Any user
>> that wants to use it can still invoke chmod() in exactly the same way
>> without a problem.

That's already what coreutils is doing.  Our point is that chmod(1) (the
coreutils userspace program) is faithfully reporting what chmod(2) (the
syscall) is returning, and therefore, if there is a buggy return value,
it is in the syscall, not in coreutils.  We are merely closing the
coreutils bug, although the kernel side of the issue may still go
somewhere (at which point coreutils will automatically pick up on a
fixed kernel).

>> As for insane filesystems like vfat(and possibly ntfs though I'm not
>> the surest as apparently I once read somewhere it has some sort of
>> POSIX compatibility mode)
>> I think users will appreciate at the least a nonzero exit code.

Possible only if the kernel gives us indication of failure; but right
now, it doesn't.

>> How difficult would it be to have chmod() modified to check "is this
>> shit vfat?" and return -1 like for any other error if it is?

chmod(1) the program?  Too hard.  We don't want to waste extra syscalls
on every successful chmod(2) syscall just to see if it "succeeded"
because the kernel lied to us.

chmod(2) the kernel syscall?  Probably not too hard, since patches were
already present that did that once; but too disruptive, as evidenced by
those patches being ripped back out at that time.

>> 2. Since this appears like a kernel issue obviously I'll have to take
>> it up with them. I'm not that familiar(OK more like totally ignorant)
>> with the inner workings of the kernel nor it's development process and
>> am kind of confused with regards to exactly who I would have to take
>> this up with.
>> I heard also that they're very tough to deal with at times so any
>> advice regarding how to approach them would be heavily appreciated.

Alas, my personal track record with kernel folks is about the same, so I
have no advice to offer.

>>
>> 3. Say things don't work out in talking with the kernel devs. What I
>> think may(this being the key word here) be a plausible workaround is
>> if you guys could somehow test even without relying
>> on chmod() what kind of filesystem are we dealing with.

Nope, we'd rather not second guess the kernel, as that will slow down
the common case.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #37 received at 12494 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Georgiy Treyvus <georgiytreyvus <at> riseup.net>
Cc: 12494 <at> debbugs.gnu.org
Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod
	fails)
Date: Wed, 26 Sep 2012 10:27:14 +0200

Georgiy Treyvus wrote:
> On 9/25/12 3:00 AM, GNU bug Tracking System wrote:
>> Your bug report
>>
>> #12494: 0 exit status even when chmod fails
...
> Wait. Before you folks put the final nail in the coffin I have three
> points/questions:

Thanks for replying.
That shows that while it was a foregone conclusion to those of us who have
dealt with this sort of issue before, it wasn't clear to everyone reading.
Thanks to Eric's explanation, you should now see why we cannot afford
to work around such brokenness: neither in chmod(1) nor via a chmod(2)
wrapper.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.