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

[Eric Blake]

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 address@hidden
>>>
>> 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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature