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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Georgiy Treyvus <georgiytreyvus <at> riseup.net>
Subject: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod
 fails)
Date: Tue, 25 Sep 2012 07:00:03 +0000

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

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 to 12494 <at> debbugs.gnu.org.

-- 
12494: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12494
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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 part 3 (message/rfc822, inline)]

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.

Previous Next

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