Subject: Re: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails)

From: Georgiy Treyvus <[email-masked]>
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 [email-masked].
>>
> 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)