I was looking at some different files in /proc, and observed some strange behavior. So, first of all, we know that symlinks [point to names, not files][1]. And when creating a symlink, I can both create a link to a file that doesn't exist, and I can create a link to a file and delete the file, as follows:
$ touch foo
$ touch bar
$ ln -s foo link1
$ ln -s bar link2
$ ln -s doesnotexist link3
$ rm bar
$ ls -l
gives
lrwxrwxrwx 1 root root 0 Apr 30 15:05 foo
lrwxrwxrwx 1 root root 3 Apr 30 15:05 link1 -> foo
lrwxrwxrwx 1 root root 3 Apr 30 15:05 link2 -> bar
lrwxrwxrwx 1 root root 12 Apr 30 15:05 link2 -> doesnotexist
albeit, with some funny coloring. However, when I go to the /proc interface things (not surprisingly) get weird. Let's say that I create my own program, called myprog. I call it, have it run in the background, and then find the pid. When checking the exe link, it shows my program.
$ cd /proc/3762
$ ls -la
Gives the following (sorry, also not surprising)
...
lrwxrwxrwx 1 root root 0 Apr 30 15:11 exe -> /home/user/myprog
...
However, what's actually interesting, is that when I move the file, the symlink follows it:
$ mv ~/myprog ~/other
$ ls -la
...
lrwxrwxrwx 1 root root 3 Apr 30 15:05 exe -> /home/user/other
...
What? Why did the symlink follow that file? I tried deleting the file, and in some cases got a .nfsXXX file that I couldn't remove, but in other cases, get a exe -> /dir/to/prog (deleted). Is there a way to force a symlink to track a file, rather than a path? Or, as I presume, is it some built in behavior to the procfs? If so, is that documented somewhere?
