Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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)?

share|improve this question

2 Answers 2

up vote 4 down vote accepted

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).

share|improve this answer
2  
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 Dec 15 '11 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 Dec 15 '11 at 15:51
1  
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 Dec 15 '11 at 18:29
1  
This answer misses a critical point, that a symlink contains the name of the target file. –  Keith Thompson Dec 21 '11 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). Finaly 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 DestinatioFile (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.

(3) The rm command or the unlink() system call doesn't physically remove a file; it removes the directory entry that point 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 it's inode and b) no process has the file open.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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