Tell me more ×
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.
up vote 4 down vote favorite
1

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

up vote 3 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
1  
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
@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
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
up vote 1 down vote

A symbolic link is a small file that contains the name of the target file, with a flag in the directory entry indicating that it's a symlink.

When you open a symlink, the OS resolves the name of the target file. If the target itself is a symlink, it resolves its name as well; there's a limit on the number of levels. (Things get a bit more complex if the name in the symlink is a relative path.)

Once the name is resolved to the name of a file that's not a symlink, that file is opened normally. The open filehandle or descriptor refers to the file itself, not to the symlink that was used to open it, and not even to the directory entry that contains its actual name. Once a program has the file open, changing the name, changing the symlink, or even unlinking the file has no effect on the program; it's still reading the same file.

Most operations treat a symbolic link as if it were the actual file that it refers to. The readlink() system call is an exception to this; it reads the contents of the symlink itself. The lstat() system call is like stat(), except that it returns information on the symlink itself rather than on the file it refers to.

Note that the rm command or the unlink() system call doesn't necessarily physically remove a file; it removes its directory entry. The file itself is removed when there are no more directory entries (hard links) that refer to it, and when 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.