Re: Quasi-(un)deletion question

[Martin Dickopp <martin-deb@zero-based.org>]

Tim Otten <tim@cap.american.edu> 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. :)

> tim@truffula:/tmp$ echo This is a test > t.txt
> tim@truffula:/tmp$ tail -f t.txt > /dev/null &
> [1] 15538
> tim@truffula:/tmp$ ln -s t.txt t.txt-symlink
> tim@truffula:/tmp$ rm t.txt
> tim@truffula:/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