fat32 chmod error codes produce non-intuitive messages
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Triaged
|
Low
|
Unassigned |
Bug Description
Binary package hint: xfce4-terminal
I know, it was a dumb idea... trying to chmod a file on my shared win/linux fat32 partition. However, the error message "Operation not permitted" was not very helpful because it seemed to say that I had done something _forbidden_, whereas it is _impossible_.
It could be something like:
"This file system does not support read/write/execute rights for different users."
And, if you want to tell the dual booters that they are a weird kind of people, add: "Use a better file system if you want to chmod."
:-)
Hope this helps to improve the trans-usability for people who are trying to slowly get away from windows. Assume I don't know _why_ I cannot set the rights - I would dispair.
Have a nice time, and thanks to everyone who is working on (x)Ubuntu!
Christoph
Changed in coreutils (Ubuntu): | |
importance: | Undecided → Low |
This is one of those parts of Unix that you're probably just going to have to get used to.
Unfortunately, there are standards (e.g. POSIX.1) that say what possible error codes a system call is allowed to return, and what they imply for that system call. run linux.die. net/man/ 2/chmod
man 2 chmod
to see the manual for the chmod system call (which the chmod(1) program is built around). Or online at e.g.
http://
It's unfortunate, because none of them are really appropriate for the situation. EIO could make sense, but it usually implies serious/unexpected problems (e.g. hard drive failure or network outage). EROFS (read only filesystem) is only true in so far as file permissions aren't modifiable.
So for chmod(1) (the program) to print a better error message:
1. it would have to try to find out if the filesystem was FAT or similar if it saw an EPERM error code. Not going to happen; Programs usually just print the standard text for an error message and print what they were trying to do when it happened. The user can tell exactly what's going on (even in a program more complicated than chmod). If programs tried to diagnose problems further, they'd all print different error messages, so it would be hard to tell what actually happened in the probably common case that the program misdiagnosed the problem. (and programs would be twice as big, and people would have to spend lots of time fixing bugs in the error-diagnosing code, esp. since most error handling code in most programs doesn't get much testing even currently. Think about how bad it would be if lots of programs tried to have special handling for strange corner cases. (I realize you weren't arguing for this whole strawman I've put up, I'm just trying to explain why Unix is how it is. The point is that chmod would have to be a much fancier program to do what you suggest, but Unix (esp. traditional command line) is all about small, sharp tools that do one thing well.))
or 2. Linux (the kernel) could return an error code not allowed by the standards for chmod(2) (the system call). This could happen; GNU = GNU is Not Unix, so they're not afraid to violate Unix standards when the standards suck. (Linux tries pretty hard to conform to most standards, though.) fat isn't POSIX compliant, (e.g. it doesn't support chmod), so one could argue that Linux doesn't need to be POSIX-compliant when using it. ENOTSUP (Operation not supported) would seem the most appropriate error code. EINVAL (Invalid argument) would work too. (see the errno(3) manpage)
Yeah, that's actually not a bad idea. I can hardly imagine it breaking anything to return ENOTSUP from chmod, since almost everything deals with errno by just looking up the associated string and printing it. Since there is just one global table, not per-system call or anything, programs would just print out "operation not supported". So I vote for changing fat's chmod handler function.
This bug should be assigned to the linux-source package, since that's the only sensible place to change anything to fix it.