This is on a Mac but I figure it's a Unixy issue.

I just forked a Github repo (this one) and cloned it to a USB stick (the one that came with the device for which the repo was made). Upon lsing I notice that README.md sticks out in red. Sure enough, its permissions are:

-rwxrwxrwx  1 me  staff   133B 15 Jun 08:59 README.md*

I try running chmod 644 README.md but there's no change. What's going on here?

  • 5
    What is the filesystem on the USB (FAT or NTFS perhaps)? – steeldriver Jun 15 '18 at 17:48
  • try git update-index --chmod=-x – Steven Penny Jun 15 '18 at 17:50
  • @steeldriver Ahhh yes, it's FAT32! Strange, given that the device itself runs Linux. – Igid Jun 15 '18 at 17:54
  • 3
    It's the filesystem, not the operating system, that determines what modes can be set on files. – Kusalananda Jun 15 '18 at 17:57
  • 1
    Check the code out on a Linux filesystem? – Andy Dalton Jun 15 '18 at 18:00

Because the 'executability' of a file is a property of the file entry on UNIX systems, not of the file type like it is on Windows.

In short, ls will list a file as being executable if any of the owner, group, or everyone has execute permissions for the file. It doesn't care what the file type is, just what the permissions are. This behavior gives two significant benefits:

  1. You don't have to do anything special to handle new executable formats. This is particularly useful for scripting languages, where you can just embed the interpreter with a #! line at the top of the file. The kernel doesn't have to know that .py files are executable, because the permissions tell it this. This also, when combined with binfmt_misc support on Linux, makes it possible to do really neat things such as treating Windows console programs like native binaries if you have Wine installed.
  2. It lets you say that certain files that are technically machine code can't or shouldn't be executed. This is also mostly used with scripting languages, where it's not unusual to have libraries that are indistinguishable in terms of file format form executables. So, using the python example above, it lets you say that people shouldnt' be able to run arbitrary modules form the Python standard library directly, even though they have a .py extension.

However, this all kind of falls apart if you're stuck dealing with filesystems that don't support POSIX permissions, such as FAT (or NTFS if you don't have user-mappings set up). If the filesystem doesn't store POSIX permissions, then the OS has to simulate them. On Linux the default is to have read write and execute permissions set for everyone, so that users can just do what they want with the files. Without this, you wouldn't be able to execute scripts or binaries off of a USB flash drive, because the kernel doesn't let you modify permissions on such filesystems per-file.

In your particular case, git stores the attributes it sees on the files when they are committed, and the original commit of the README.md file (or one of the subsequent commits to it) probably happened on a Windows system, where such things are handled very differently, and thus git just stores the permissions as full access for everyone, similarly to how Linux handles fiesystems without permissions support.

  • There's some great information in this answer but it doesn't quite explain why Unix sees files on non-compatible filesystems as -rwxrwxrwx – Igid Jun 16 '18 at 13:58
  • @lgid If it would default to, say, -r--, or -rw-, no files on a FAT drive would be executable if mounted on a Unix system. And applications might even get confused if directories miss the ---x part. – nohillside Jun 16 '18 at 18:36
  • Ah yeah, makes sense – Igid Jun 18 '18 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.