Tim Otten <[EMAIL PROTECTED]> writes: >> /proc/PID/fd seems to work just fine; see transcript below. > > OMG. That does work. I didn't try it because the file looks like a symlink > in 'ls' -- a similar process with symlinks on a normal filesystem will > produce different results:
Yes, /proc is quite different from other filesystems in many ways. :) > [EMAIL PROTECTED]:/tmp$ echo This is a test > t.txt > [EMAIL PROTECTED]:/tmp$ tail -f t.txt > /dev/null & > [1] 15538 > [EMAIL PROTECTED]:/tmp$ ln -s t.txt t.txt-symlink > [EMAIL PROTECTED]:/tmp$ rm t.txt > [EMAIL PROTECTED]:/tmp$ cat t.txt-symlink > cat: t.txt-symlink: No such file or directory > > So the proc filesystem somehow provides hardlink semantics with a > symlink facade? The behavior is similar to hardlinks, but it's not really a hardlink, since hardlinks cannot work between different filesystems. A hardlink in the strict sense means that two or more directory entries refer to the same inode. That's not what's happening here. When the kernel is asked what type of file it is (as 'ls' does), it claims that it is a symlink. But when the kernel is asked for the content of the file (as 'cat' does), it returns the content of the open file on another filesystem. These two system-calls are really independent of each other, so the kernel can do that. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
