I mean what's going on when some process wants to read a symlink? What's going on when something changes a symlink during a read or even write process?

For example: I have 2 huge, similar 100G files /mnt/1 and /mnt/2. /mnt/1 is available via the symlink /home/user/file. Some program A starts reading /home/user/file. And after a while something changes the link from /mnt/1 to /mnt/2, but A is still reading the file.

Does the program cache the absolute path?

Will it fail and error, because the symlink was changed or will it work fine, like nothing happened?

Will it differ in case /home/user/file is linked to a block device (for example 2 replicated iscsi disks)?

3 Answers 3


The symlink points to the name of the real file (inode) in the file system. When the system resolves that symlink to find the actual file and open it, it finds and uses the file's inode. At that point, the path you used to get to the file doesn't matter. What the OS doesn't cache, it reads from the file by its inode. You could, as I understand, start reading the file through a hard link and remove that hard link (as long as the file is still linked from somewhere else), and it wouldn't cause problems as long as the file has been resolved (name string->inode).

  • 4
    You can remove ALL links to the file and still keep reading it once you have it open. This is why you can upgrade packages without rebooting like you have to on windows; because you can rm the program executable file even though it is running.
    – psusi
    Commented Dec 15, 2011 at 15:45
  • 1
    @psusi I know the data and inode are still there and just not pointed to any more, but once the file has been deleted, the system is free to overwrite that spot on disk, right? So if the file is too large to fit in the file cache, like the 100GB files in question, what happens if part of them is overwritten before you get to the end? This isn't a concern for critical system files because they are loaded into cache and kept there, but 100GB is big enough that I think this could be a concern.
    – Kevin
    Commented Dec 15, 2011 at 15:51
  • 2
    Kevin, files didn't remove from disk until last process that use file dies. You can always find all files that are in use at the moment in proc. But your answer seems explained my question. Thanks.
    – rush
    Commented Dec 15, 2011 at 18:29
  • 2
    This answer misses a critical point, that a symlink contains the name of the target file. Commented Dec 21, 2011 at 0:29

A symbolic link is a small file that contains the location (i.e. path and filename) of a target file, with a flag in the directory entry indicating that it's a symlink.

When you open a symlink, the OS will follow the location to find the target file. If the target is itself a symlink, it follows its location as well (1)(2) until the location points to a file that's not a symlink (let's call it the FinalFile). Then the OS obtains the inode of the FinalFile (the inode contains metadata like modification-time and has also a pointer to the file's data). Finally the inode of the FinalFile is opened. From now on the process uses that inode to read/write to the file. As a result changing the symlink name or path, deleting the symlink, changing the path or the name of the FinalFile or even deleting the FinalFile(3) has no effect on the process; it's still reading from the same inode.

In most cases file-data operations on the symlink will affect the FinalFile (e.g. reading and writing to the symlink will read from/write to the FinalFile) but there are exceptions: the readlink() system call reads the contents of the symlink itself.

File-metadata operations (like rename or delete) on the other hand will usually affect the symlink. But there are exceptions here as well: the lstat() system call is like stat(), except that it returns information on the symlink itself rather than on the FinalFile(2).

(1) There's a limit on the number of levels and things get a bit more complex if the location in the symlink is a relative path.

(2) Read symlink(7): symbolic link handling for more details. man 7 symlink

(3) The rm command or the unlink() system call doesn't physically remove a file. It removes the directory entry that points to the inode of the file. The file itself is removed only if both a) there are no more directory entries (hard links) that refer to its inode and b) no process has the file open.


That is almost transparent for Linux, and it is much more relationed to the filesystem you are using than the operational system.

It is not a regular file, or a very small file because you cannot create a working symbolic link in a VFAT partition for example by just copying the symbolic link itself to it, because it is recorded directly by the filesystem.

The difference in the symbolic link to a hard link is that the appointement is to a hard link instead of poiting to the data sectors like a hard link does.


Test 1:

echo 'data' >file.txt

This will create the hard link file.txt pointing to sectors 10 to 20* (*numbers just for explaining).

Test 2:

Now what if ?

ln file.txt file_2.txt

This created a hardlink file_2.txt pointing to sectors 10 to 20 (the same of file.txt), so if you delete file.txt, sectors 10 to 20 are still reserved, and you can see data inside file_2.txt... . (file.txt and file_2.txt are both like the originals)

Test 3:

ln -s file.txt file_sym.txt 

Pointed symbolic link file_sym.txt to the hard link file.txt, so when you try to access file_sym.txt you will see file.txt, but if you delete file.txt file_sym will not find the target anymore.

Those are managed by the filesystem, for example by the ext4 modules for linux (or if it is compiled on the kernel), it does not matter if you are using Linux or other Unix.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .