bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Georgiy Treyvus
Subject: bug#12494: closed (Re: bug#12494: 0 exit status even when chmod fails)
Date: Tue, 25 Sep 2012 13:56:22 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

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.

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!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]