From unknown Mon Jun 23 18:28:31 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#12494 <12494@debbugs.gnu.org> To: bug#12494 <12494@debbugs.gnu.org> Subject: Status: 0 exit status even when chmod fails Reply-To: bug#12494 <12494@debbugs.gnu.org> Date: Tue, 24 Jun 2025 01:28:31 +0000 retitle 12494 0 exit status even when chmod fails reassign 12494 coreutils submitter 12494 Georgiy Treyvus severity 12494 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 23 14:20:10 2012 Received: (at submit) by debbugs.gnu.org; 23 Sep 2012 18:20:10 +0000 Received: from localhost ([127.0.0.1]:51490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFqmm-0003hk-Gf for submit@debbugs.gnu.org; Sun, 23 Sep 2012 14:20:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48075) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFfG2-0002vM-AS for submit@debbugs.gnu.org; Sun, 23 Sep 2012 02:01:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TFfEI-00083W-Gl for submit@debbugs.gnu.org; Sun, 23 Sep 2012 01:59:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:47425) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TFfEI-00083S-Dw for submit@debbugs.gnu.org; Sun, 23 Sep 2012 01:59:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TFfEH-0005Vb-Bc for bug-coreutils@gnu.org; Sun, 23 Sep 2012 01:59:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TFfEG-00083E-BU for bug-coreutils@gnu.org; Sun, 23 Sep 2012 01:59:45 -0400 Received: from mx1.riseup.net ([204.13.164.18]:60754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TFfEG-000834-5a for bug-coreutils@gnu.org; Sun, 23 Sep 2012 01:59:44 -0400 Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 1FA9E5C329 for ; Sat, 22 Sep 2012 22:59:42 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: georgiytreyvus@fulvetta.riseup.net) with ESMTPSA id A697F264 Message-ID: <505EA549.3040407@riseup.net> Date: Sun, 23 Sep 2012 01:59:37 -0400 From: Georgiy Treyvus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: bug-coreutils@gnu.org Subject: 0 exit status even when chmod fails Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at mx1 X-Virus-Status: Clean X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 23 Sep 2012 14:20:06 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 24 02:31:14 2012 Received: (at 12494) by debbugs.gnu.org; 24 Sep 2012 06:31:14 +0000 Received: from localhost ([127.0.0.1]:51977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TG2CH-0006Mc-Gm for submit@debbugs.gnu.org; Mon, 24 Sep 2012 02:31:14 -0400 Received: from smtp.cs.ucla.edu ([131.179.128.62]:56256) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TG2CD-0006MT-Hh for 12494@debbugs.gnu.org; Mon, 24 Sep 2012 02:31:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9BCBFA60004; Sun, 23 Sep 2012 23:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3Hd7SSdkXx5; Sun, 23 Sep 2012 23:29:16 -0700 (PDT) Received: from [192.168.1.3] (pool-108-23-119-2.lsanca.fios.verizon.net [108.23.119.2]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 09A11A60002; Sun, 23 Sep 2012 23:29:16 -0700 (PDT) Message-ID: <505FFDB9.2060109@cs.ucla.edu> Date: Sun, 23 Sep 2012 23:29:13 -0700 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Georgiy Treyvus Subject: Re: bug#12494: 0 exit status even when chmod fails References: <505EA549.3040407@riseup.net> In-Reply-To: <505EA549.3040407@riseup.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 12494 Cc: 12494@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 24 02:39:12 2012 Received: (at 12494) by debbugs.gnu.org; 24 Sep 2012 06:39:12 +0000 Received: from localhost ([127.0.0.1]:52005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TG2Jz-0006Zj-HF for submit@debbugs.gnu.org; Mon, 24 Sep 2012 02:39:12 -0400 Received: from c-67-162-91-36.hsd1.in.comcast.net ([67.162.91.36]:35781 helo=kosh.dhis.org) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TG2Jx-0006Zc-RF for 12494@debbugs.gnu.org; Mon, 24 Sep 2012 02:39:10 -0400 Received: (qmail 4404 invoked by uid 1000); 24 Sep 2012 06:37:16 -0000 Message-ID: <20120924063716.4403.qmail@kosh.dhis.org> From: "Alan Curry" Subject: Re: bug#12494: 0 exit status even when chmod fails To: georgiytreyvus@riseup.net (Georgiy Treyvus) Date: Mon, 24 Sep 2012 01:37:16 -0500 (GMT+5) In-Reply-To: <505EA549.3040407@riseup.net> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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.) [...] Content analysis details: (2.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [67.162.91.36 listed in zen.spamhaus.org] 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [67.162.91.36 listed in dnsbl.sorbs.net] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS X-Debbugs-Envelope-To: 12494 Cc: 12494@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 2.4 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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.) [...] Content analysis details: (2.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [67.162.91.36 listed in zen.spamhaus.org] 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [67.162.91.36 listed in dnsbl.sorbs.net] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 24 15:23:16 2012 Received: (at 12494) by debbugs.gnu.org; 24 Sep 2012 19:23:17 +0000 Received: from localhost ([127.0.0.1]:53634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGEFQ-00024J-I8 for submit@debbugs.gnu.org; Mon, 24 Sep 2012 15:23:16 -0400 Received: from mailout-de.gmx.net ([213.165.64.22]:59966) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGEFO-00024A-3K for 12494@debbugs.gnu.org; Mon, 24 Sep 2012 15:23:15 -0400 Received: (qmail invoked by alias); 24 Sep 2012 19:21:17 -0000 Received: from p4FC63B82.dip.t-dialin.net (EHLO turtle.gmx.de) [79.198.59.130] by mail.gmx.net (mp030) with SMTP; 24 Sep 2012 21:21:17 +0200 X-Authenticated: #28250155 X-Provags-ID: V01U2FsdGVkX18S7almMIgSPVwZauxJBR7/DoVDTMejJxcXHWxw47 2XZkroEJsEs23d Received: by turtle.gmx.de (Postfix, from userid 1000) id 21AE83F46A; Mon, 24 Sep 2012 21:21:18 +0200 (CEST) From: Sven Joachim To: "Alan Curry" Subject: Re: bug#12494: 0 exit status even when chmod fails References: <505EA549.3040407@riseup.net> <20120924063716.4403.qmail@kosh.dhis.org> Date: Mon, 24 Sep 2012 21:21:18 +0200 In-Reply-To: <20120924063716.4403.qmail@kosh.dhis.org> (Alan Curry's message of "Mon, 24 Sep 2012 01:37:16 -0500 (GMT+5)") Message-ID: <87haqntefl.fsf@turtle.gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12494 Cc: Georgiy Treyvus , 12494@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 24 15:27:13 2012 Received: (at 12494) by debbugs.gnu.org; 24 Sep 2012 19:27:13 +0000 Received: from localhost ([127.0.0.1]:53640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGEJF-0002AF-5w for submit@debbugs.gnu.org; Mon, 24 Sep 2012 15:27:13 -0400 Received: from c-67-162-91-36.hsd1.in.comcast.net ([67.162.91.36]:40529 helo=kosh.dhis.org) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGEJD-0002A8-9c for 12494@debbugs.gnu.org; Mon, 24 Sep 2012 15:27:11 -0400 Received: (qmail 22401 invoked by uid 1000); 24 Sep 2012 19:25:15 -0000 Message-ID: <20120924192514.22400.qmail@kosh.dhis.org> From: "Alan Curry" Subject: Re: bug#12494: 0 exit status even when chmod fails To: svenjoac@gmx.de (Sven Joachim) Date: Mon, 24 Sep 2012 14:25:14 -0500 (GMT+5) In-Reply-To: <87haqntefl.fsf@turtle.gmx.de> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. [...] Content analysis details: (3.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [67.162.91.36 listed in dnsbl.sorbs.net] 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, https://senderscore.org/blacklistlookup/ [67.162.91.36 listed in bl.score.senderscore.com] 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [67.162.91.36 listed in zen.spamhaus.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS X-Debbugs-Envelope-To: 12494 Cc: 12494@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 3.7 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. [...] Content analysis details: (3.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [67.162.91.36 listed in zen.spamhaus.org] 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [67.162.91.36 listed in dnsbl.sorbs.net] 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, https://senderscore.org/blacklistlookup/ [67.162.91.36 listed in bl.score.senderscore.com] 0.0 SINGLE_HEADER_2K A single header contains 2K-3K characters -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 24 16:37:26 2012 Received: (at 12494) by debbugs.gnu.org; 24 Sep 2012 20:37:26 +0000 Received: from localhost ([127.0.0.1]:53671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGFPB-0003hY-W1 for submit@debbugs.gnu.org; Mon, 24 Sep 2012 16:37:26 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:42356) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1TGFP9-0003hP-0r for 12494@debbugs.gnu.org; Mon, 24 Sep 2012 16:37:23 -0400 Received: (qmail invoked by alias); 24 Sep 2012 20:35:25 -0000 Received: from p4FC63B82.dip.t-dialin.net (EHLO turtle.gmx.de) [79.198.59.130] by mail.gmx.net (mp069) with SMTP; 24 Sep 2012 22:35:25 +0200 X-Authenticated: #28250155 X-Provags-ID: V01U2FsdGVkX1/B2d4/EFHBxeG/FfB7TonM42rW+CN2JNLqqkw/PL GKc6Fym5fRnIif Received: by turtle.gmx.de (Postfix, from userid 1000) id F39C73F46A; Mon, 24 Sep 2012 22:35:27 +0200 (CEST) From: Sven Joachim To: "Alan Curry" Subject: Re: bug#12494: 0 exit status even when chmod fails References: <505EA549.3040407@riseup.net> <20120924192514.22400.qmail@kosh.dhis.org> Date: Mon, 24 Sep 2012 22:35:27 +0200 In-Reply-To: <20120924192514.22400.qmail@kosh.dhis.org> (Alan Curry's message of "Mon, 24 Sep 2012 14:25:14 -0500 (GMT+5)") Message-ID: <873927tb00.fsf@turtle.gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 12494 Cc: 12494@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 25 02:59:49 2012 Received: (at 12494-done) by debbugs.gnu.org; 25 Sep 2012 06:59:49 +0000 Received: from localhost ([127.0.0.1]:54249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGP7U-0002lz-Lr for submit@debbugs.gnu.org; Tue, 25 Sep 2012 02:59:48 -0400 Received: from mx.meyering.net ([88.168.87.75]:54261) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGP7Q-0002ll-Le for 12494-done@debbugs.gnu.org; Tue, 25 Sep 2012 02:59:46 -0400 Received: from rho.meyering.net (rho.meyering.net [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id D5628601F8; Tue, 25 Sep 2012 08:57:41 +0200 (CEST) From: Jim Meyering To: Sven Joachim Subject: Re: bug#12494: 0 exit status even when chmod fails In-Reply-To: <873927tb00.fsf@turtle.gmx.de> (Sven Joachim's message of "Mon, 24 Sep 2012 22:35:27 +0200") References: <505EA549.3040407@riseup.net> <20120924192514.22400.qmail@kosh.dhis.org> <873927tb00.fsf@turtle.gmx.de> Date: Tue, 25 Sep 2012 08:57:41 +0200 Message-ID: <87a9weio7u.fsf@rho.meyering.net> Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 12494-done Cc: 12494-done@debbugs.gnu.org, Alan Curry X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 25 13:58:41 2012 Received: (at 12494) by debbugs.gnu.org; 25 Sep 2012 17:58:41 +0000 Received: from localhost ([127.0.0.1]:55604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGZP7-0003VX-Bo for submit@debbugs.gnu.org; Tue, 25 Sep 2012 13:58:41 -0400 Received: from mx1.riseup.net ([204.13.164.18]:34813) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGZP3-0003VN-RD for 12494@debbugs.gnu.org; Tue, 25 Sep 2012 13:58:39 -0400 Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 436CE61C50 for <12494@debbugs.gnu.org>; Tue, 25 Sep 2012 10:56:36 -0700 (PDT) Received: from ool-457c714e.dyn.optonline.net (ool-457c714e.dyn.optonline.net [69.124.113.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: georgiytreyvus@fruiteater.riseup.net) by fruiteater.riseup.net (Postfix) with ESMTPSA id BE6A4719 for <12494@debbugs.gnu.org>; Tue, 25 Sep 2012 10:56:35 -0700 (PDT) Message-ID: <5061F046.2010608@riseup.net> Date: Tue, 25 Sep 2012 13:56:22 -0400 From: Georgiy Treyvus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: 12494@debbugs.gnu.org Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails) References: <87a9weio7u.fsf@rho.meyering.net> <505EA549.3040407@riseup.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010107040802040505010806" X-Virus-Scanned: clamav-milter 0.97.5 at mx1 X-Virus-Status: Clean X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 12494 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) This is a multi-part message in MIME format. --------------010107040802040505010806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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@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! --------------010107040802040505010806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
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 to 12494@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!


--------------010107040802040505010806-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 25 14:04:43 2012 Received: (at 12494) by debbugs.gnu.org; 25 Sep 2012 18:04:43 +0000 Received: from localhost ([127.0.0.1]:55635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGZUx-0003fC-7h for submit@debbugs.gnu.org; Tue, 25 Sep 2012 14:04:43 -0400 Received: from mx1.riseup.net ([204.13.164.18]:38925) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGZUu-0003f4-8g for 12494@debbugs.gnu.org; Tue, 25 Sep 2012 14:04:41 -0400 Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id C8EFC62F77 for <12494@debbugs.gnu.org>; Tue, 25 Sep 2012 11:02:36 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: georgiytreyvus@fulvetta.riseup.net) with ESMTPSA id 6B15C5F9 Message-ID: <5061F1B1.3070909@riseup.net> Date: Tue, 25 Sep 2012 14:02:25 -0400 From: Georgiy Treyvus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: 12494@debbugs.gnu.org Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails) References: <87a9weio7u.fsf@rho.meyering.net> <505EA549.3040407@riseup.net> <5061F046.2010608@riseup.net> In-Reply-To: <5061F046.2010608@riseup.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at mx1 X-Virus-Status: Clean X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 12494 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) 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@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) From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 25 16:49:43 2012 Received: (at 12494) by debbugs.gnu.org; 25 Sep 2012 20:49:43 +0000 Received: from localhost ([127.0.0.1]:55833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGc4d-0008Ql-22 for submit@debbugs.gnu.org; Tue, 25 Sep 2012 16:49:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14811) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGc4Z-0008Qa-Nw for 12494@debbugs.gnu.org; Tue, 25 Sep 2012 16:49:42 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8PKla5E021571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Sep 2012 16:47:37 -0400 Received: from [10.3.113.152] (ovpn-113-152.phx2.redhat.com [10.3.113.152]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q8PKla2T012513; Tue, 25 Sep 2012 16:47:36 -0400 Message-ID: <50621866.9060904@redhat.com> Date: Tue, 25 Sep 2012 14:47:34 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Georgiy Treyvus Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails) References: <87a9weio7u.fsf@rho.meyering.net> <505EA549.3040407@riseup.net> <5061F046.2010608@riseup.net> <5061F1B1.3070909@riseup.net> In-Reply-To: <5061F1B1.3070909@riseup.net> X-Enigmail-Version: 1.4.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigEC90572B5E7DF970AD9F496D" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -7.7 (-------) X-Debbugs-Envelope-To: 12494 Cc: 12494@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.7 (-------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC90572B5E7DF970AD9F496D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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@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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigEC90572B5E7DF970AD9F496D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQYhhnAAoJEKeha0olJ0NqoC8H/0Ru/mMLcGUBlPUeIgJ2Zgfa KJdoB1BxTmryh0w1Qu7qthf5VNslcuiUzLYvccB+2z9+PwxNxfidBljwaEM/pMEL yUQsnOnEgsZEcGCMDMpOyLVsdQISAiUKMjhv4cBV2+lNCo70Rbek1QININb9YFmQ X3vCxbjl4iO5HiutmJYShqQl5ITBY7LJSGKsSWFKWcXCUT+aRdMTn7GkVNAv/LJf vMbmMcK+dGvrQt3d4IBEiXRB/AhS+I/TPA+68ve9qvmP9T8kgU+DmuvmO4PfeXJC vGF6Q25v57QIBxUIuMyCw0SikDlHQBB7hK3qjeo4KxEJxGLghFGzwkjEubMtwJ8= =39iR -----END PGP SIGNATURE----- --------------enigEC90572B5E7DF970AD9F496D-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 26 04:27:16 2012 Received: (at 12494) by debbugs.gnu.org; 26 Sep 2012 08:27:16 +0000 Received: from localhost ([127.0.0.1]:56309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGmxf-0000dW-SL for submit@debbugs.gnu.org; Wed, 26 Sep 2012 04:27:16 -0400 Received: from mx.meyering.net ([88.168.87.75]:58191) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TGmxd-0000dN-M4 for 12494@debbugs.gnu.org; Wed, 26 Sep 2012 04:27:14 -0400 Received: from rho.meyering.net (rho.meyering.net [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 6BDB2600BD; Wed, 26 Sep 2012 10:27:14 +0200 (CEST) From: Jim Meyering To: Georgiy Treyvus Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails) In-Reply-To: <5061F046.2010608@riseup.net> (Georgiy Treyvus's message of "Tue, 25 Sep 2012 13:56:22 -0400") References: <87a9weio7u.fsf@rho.meyering.net> <505EA549.3040407@riseup.net> <5061F046.2010608@riseup.net> Date: Wed, 26 Sep 2012 10:27:14 +0200 Message-ID: <87ehlpgpel.fsf@rho.meyering.net> Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 12494 Cc: 12494@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) 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. From unknown Mon Jun 23 18:28:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 24 Oct 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator