Does pipe's link target exist somewhere in the filesystem?

Question

I'm talking about this:

$ readlink <(echo test)
pipe:[80076194]

Is pipe:[80076194] a path to the target or just indication that the file descriptor is connected to the pipe and doesn't exist in filesystem? The main reason I'm asking is due to php for one trying to dereference it:

$ strace -f php -r 'var_dump(file_get_contents($_SERVER["argv"][1]));' -- <(echo test)
...
[pid   654] lstat("/dev/fd/63", {st_mode=S_IFLNK|0500, st_size=64, ...}) = 0
[pid   654] readlink("/dev/fd/63", "pipe:[80095114]", 4096) = 15
[pid   654] lstat("/dev/fd/pipe:[80095114]", 0x7fff9c3628a0) = -1 ENOENT (No such file or directory)
[pid   654] lstat("/dev/fd", {st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
[pid   654] readlink("/dev/fd", "/proc/self/fd"..., 4096) = 13
[pid   654] lstat("/proc/self/fd", {st_mode=S_IFDIR|0500, st_size=0, ...}) = 0
[pid   654] lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=64, ...}) = 0
[pid   654] readlink("/proc/self", "654"..., 4096) = 3
[pid   654] lstat("/proc/654", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid   654] lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid   654] open("/proc/654/fd/pipe:[80095114]", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid   654] write(2, "PHP Warning:  file_get_contents("..., 125PHP Warning:  file_get_contents(/dev/fd/63): failed to open stream: No such file or directory in Command line code on line 1
) = 125
[pid   654] write(1, "bool(false)\n", 12bool(false)
) = 12

Answer 1

In short, no it does not exist.

 

In long:

There are 2 types of pipes in linux, named pipes (aka, fifo), and anonymous pipes.

Named pipes are created with the mkfifo (man 3 mkfifo) system call. Named pipes exist as files on the filesystem. One process opens it for reading, and another opens it for writing.

Anonymous pipes are created with the pipe (man 2 pipe) system call. Once opened, they behave exactly the same as opening a mkfifo pipe. They take up a file descriptor, one end is open for reading, the other is open for writing.

Because they take up a file descriptor, they show up in /proc/PID/fd/. But since they don't exist as an actual file anywhere, the entry in /proc/PID/fd/ has to do a little magic. So basically the pipe becomes represented as symlink with a fake target. When you open the symlink, the kernel really opens the pipe that is represented by the symlink. But since it's a symlink, and symlinks have targets, anything which tries to dereference the symlink (not implicitly via the kernel) will get back a target. It's just that this target does not point to a valid file.

Normally you cannot do this with symlinks, however the /proc filesystem is not a normal filesystem. It's a fake filesystem represented by the kernel. And since the contents are created by the kernel, the kernel can break its own rules.