fat32 chmod error codes produce non-intuitive messages

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.

Hi Christoph,
Unfortunately, you didn't specify which version of (x)ubuntu you were using. Do you know if this is still an issue in a supported version, i.e. Hardy onwards. Also, are you able to test this in Karmic.
Thank you.

mount -t vfat has a "quiet" option now. See man(1).

quiet: Turn on the quiet flag. Attempts to chown or chmod files do not return errors, although they fail. Use with caution!

 It isn't enabled by default. However, a lot of things now don't return an error at all, even without quiet. e.g.
pretty much any normal chmod operation will return "success", even if it didn't do anything. With quiet enabled, even chown will silently do nothing.

To test this,
cd /tmp
dd if=/dev/zero of=fat.img bs=1024k count=1 # 1MB file
mkfs.vfat fat.img

mkdir fat.mnt
sudo mount -o loop,uid=$USER -t vfat fat.img fat.mnt
touch fat.mnt/foo
chmod 700 fat.mnt/foo
chown root fat.mnt/foo
(run this as your regular user account, so the mount option is uid=peter, for example)

 If you look in the kernel sources (fs/fat/file.c), you can see that EPERM is still the only error code in evidence. However, it looks like it's mostly only returned when you actually don't have permission, e.g. you don't own the mount, and you're not root.

 I think ENOTSUP might be an improvement over silence, at least when you're using chmod directly. If some big GUI program is saving a file, the error messages it would print because of FAT are probably useless.

Teej: I still get the "Operation not permitted" message in Jaunty, and I can test it in Karmic one of these days.

I have marked this as Low, as I doubt there will be many trying to chmod a fat32 partition. Even by Windows standards, ntfs is the current one. I have followed the above test conditions, and can confirm that this indeed is still a problem in Karmic, coreutils version 7.4-2ubuntu1 - I believe there is enough information here to mark this Triaged, and so I will let a developer take it from here. Thank you.

> I have marked this as Low, as I doubt there will be many trying to chmod a fat32 partition.

 The usual situation for me was cp -a foo/*.mp3 /mnt/sd-usb/audiobooks/
cp -a would print an error as it tried to chown every file, although setting the mod time succeeded.
With Jaunty, tt doesn't print that error anymore. I tried with a real SD card in my USB reader, instead of using the loopback test I did before. Although I'm not using gnome or KDE with their device managers. My results differ from yours, Teej, so it's either device managers mounting with different options, or the kernel in Karmic returns errors for more cases than Jaunty. My kernel is built from Jaunty sources, but with my own config:
Linux version 2.6.28-15-tesla (root@tesla) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #52 SMP Fri Aug 28 19:19:22 ADT 2009

 I wouldn't be surprised if Karmic is noisier, since some things that Jaunty doesn't return an error for should probably only be that way with mount -o quiet.

> Even by Windows standards, ntfs is the current one.

 fat is what you'll find on most flash-based removable storage (sd cards, USB flash drives, digital audio players, etc.).

 BTW, coreutils version doesn't matter. All versions of cp and esp. chmod will make the same system calls and report any errors that are returned. The variation will all be in what the kernel decides to return when you ask it do do something that FAT doesn't support. Mapping the Unix permission model onto FAT is the tricky part, and that code is all in the kernel. (in fs/fat/*, to be specific)