How implementation details become ABI: a case study

Following those suckers gives you vfsmount/dentry of deleted object. They are *not* followed by interpreting the result of ->readlink() (that's why ->follow_link() is an independent method). What you get opening those is *not* dup()-style extra reference to opened file; it's independently opened file over the same filesystem object (IOW, lseek() on one of those doesn't affect another). Filesystem might refuse opening it, of course; local filesystems usually do not, with network ones it's up to server. For sockets it explicitly fails; for pipes and FIFOs you get the same semantics you'd get from extra opener of named pipe.

Note that it's more than just /proc/*/fd/* - e.g. /proc/*/exe and /proc/*/cwd are also like that.

" (deleted)" is a kludge, and a damn unpleasant one. But as this story shows, it's not something we can kill ;-/ It's before my involvement, but I suspect that original motivation was lsof/fuser. And behaviour for rename(2) victim was an accident - check the history circa 2.1.40s; back when this " (deleted)" thing had been introduced *all* names had been external and d_move() swapped them in all cases. It was more about the unlinked ones... memcpy()-instead-of-swap had been introduced in 2.1.116 and it was more of "we need to put something there; just memcpy() it over".

No, it really had been an accident. BTW, prior to 2.1.43 those magic symlinks had the same semantics on follow_link, but gave "[%04x]:%u"
with st_dev and st_ino on readlink(). Next came an attempt to put something that usually gave pathname corresponding to the fs object in question, shortly followed by " (deleted)" tacked on the end of unlinked ones.