The file's contents don't change at all. Filesystems that are designed for typical Unix will support storing information about every file. This is often called the file's "meta data".
This is why you won't get similar results with some filesystems. Namely, FAT doesn't have built-in space designed for storing data related to Unix permissions, and Unix typically gets around that by using a special parameter when mounting such a filesystem volume. So, typically all files on a FAT drive have the same permissions, as specified by mounting. (I would expect similar behavior for other filesystems, like ISO9660, although that is probably usually unwritable.) On volumes mounted in this way, using chmod +x
won't actually end up changing anything.
In short, the way the kernel knows this is by checking the filesystem driver. For typical filesystems designed for unix, that driver supports reading the locations where Unix-style permissions are stored.
chmod simply changes those spots on the drive.
"If you set
+x
on a file that the kernel doesn't recognize, it'll just return an error code from theexec
syscall" -- it's not obvious when this error is returned. It's when you try to execute, not when youchmod
; right? – Kamil Maciorowski – 2017-03-21T06:39:23.087Well, it cannot possibly refer to execution of the 'chmod' command, as that happens way before anything mode-related (the actual kernel operation is the chmod syscall anyway). So that leaves (attempted) execution of the file in question. – user1686 – 2017-03-21T07:40:53.810
That makes sense thank you. Sorry for the poorly worded question. I couldn't think of how else to describe what I was asking. 'set a bit in the file's permissions' is what I was wanting to know. – StatGenGeek – 2017-03-22T03:10:17.953