GNU bug report logs -
#12494
0 exit status even when chmod fails
Previous Next
Full log
View this message in rfc822 format
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)
This bug report was last modified 12 years and 245 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.