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 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://linux.die.net/man/2/chmod 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. -- misleading error message in terminal when trying to chmod on fat32 https://bugs.launchpad.net/bugs/164507 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
