What file mode indicates that a file is a symbolic link (symlink)?

My use case is to detect symbolic links inside a git repository (and its history). I was under the impression that a symlink is a symlink because of its file mode, and that file mode is what the tool chmod sets.


File modes cover two different notions: file types and file permissions. A file's mode is represented by the value of st_mode in the result of stat(2) calls, and ls -l presents them all together; see Understanding UNIX permissions and file types for details.

Once a file is created its type can't be changed. In addition, on Linux systems you can't specify a symlink's permissions; all that matters is the target's permission (and effectively the full mode since that determines the symlink's behaviour too). See How do file permissions apply to symlinks? for details. On Mac OS X symlinks can have their own permissions.

Finally, git uses a simplified model, with a limited number of recognised modes:

  • 040000 for a directory
  • 100644 for a normal file
  • 100755 for an executable file
  • 120000 for a symbolic link

You can see these values using commands such as git cat-file -p 'master^{tree}'; see Pro Git for details.


What file mode indicates that a file is a symbolic link (symlink)?

The POSIX API to check if a file is a symlink is using the S_ISLNK macro.

In glibc, S_ISLNK is defined as follows:

#define __S_IFMT    0170000 /* These bits determine file type.  */
#define __S_IFLNK   0120000 /* Symbolic link.  */
#define __S_ISTYPE(mode, mask)  (((mode) & __S_IFMT) == (mask))
#define S_ISLNK(mode)    __S_ISTYPE((mode), __S_IFLNK)

i.e. a file is a symlink if ((mode & 0170000) == 0120000) (at least on GNU/Linux).


A symlink (though some filesystems handle symlinks differently) is an inode table entry that points to the same place as another file (or directory).

For example if foo is inode 1234 then bar (a symlink to foo) is inode 1234.

bar doesn't really exist it's just a pointer to a "real" file.

Symlinks generally don't have permissions outside the permissions of the file they point to. So bar's permissions are "the same" as foo's. You can't set permissions on bar (the symlink) only on foo (the real file).

That being said, it's a really high level view. Different file systems handle symlinks differently. Different tools handle symlinks differently. Some file systems "flag" symlinks and handle them specially, but some don't.

For example chmod on Linux won't change a symlinks permissions but on OSX you can get it to. In both cases the real files permissions are changed.

I can not think of any system (doesn't mean it's not out there) where a symlink has permissions separate from the real file.

  • 3
    No, a symlink is a type of file ("everything is a file") that contains a filename rather than general-purpose data.  Typically this filename refers to an existing file — that's the whole point of having symlinks — but this is not guaranteed to be true.  Yes, a symlink (like every other type of file) has an inode.  No, a symlink and the file it points to have separate inodes, with different inode numbers.  Hard links have the same inode, and thus the same inode number. – Scott Mar 31 '15 at 6:08
  • well it was meant to be high level but modern systems don't make a file on the hard drive the inode table contains the string and no real file is created. I think it's called "fast symlink" – coteyr Mar 31 '15 at 17:41
  • If 'foo' and 'bar' are both pointers to node 1234, then they're HARD links, not symlinks. If "bar" were a SYMlink, then it would literally be the character string "foo" (or even the path to foo) instead of an node. In fact, you can create a symlink that doesn't point anywhere meaningful at all, e.g. ln -s 'this is not a real file' bar – Edward Falk Jun 22 '16 at 1:37
  • 1
    Also: BSD (which includes Mac OS X) has an lchmod() system call which will let you set the permissions of the symlink itself. I have no idea what the use of that is. – Edward Falk Jun 22 '16 at 1:45

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.