[DSMan195276]

I think it has some minor tradeoffs, like the article mentions not all of the underlying files can be opened a second time so that makes them basically unusable in this form. If the `open()` call did a dup instead then you could read/write to it in the same way as the process can regardless of the type of underlying file.

[hawski]

Ideally I would like to see both behaviors available, making the current way the preferred one. But AFAIK it would be hard, because /dev/fd/* are just symlinks and this would need a very special case.

[tsimionescu]

But what would be the use case of re-opening your own files in this way, that dup() doesn't cover?

I mean, it's cute that it's in principle possible, but what does it actually do that can't be achieved more cleanly in other ways?

[kazinator]

It supports the wacky semantics of the freopen function, which is probably why glibc implements freopen by opening /proc/self/fd/<n>.

Specifically, the case of freopen when the path argument is null, which was introduced in C99.

freopen does all the open-time actions such as that the "w" mode truncates the file. So that could be why. If we dup the descriptor, we have to call ftruncate to implement the "w" flag. I think if we just open the /proc item, O_TRUNC will do it for us.

The freopen function is wacky in the first place, and obviously the approach has the flaw that (as we learn from the submitted article) that sockets cannot be opened this way.

Obviously, /proc/.../fd was not designed for freopen.

/proc/<other-than-self>/fd is very useful for implementing, e.g. process substitution in Bash:

  $ diff -u <(this command) <(that command)

This calls diff with /proc/<pid>/fd/<n> /proc/<pid>/fd/<m> which refer to pipes set up by the shell. The diff program thinks it's just opening files.

/proc/self/fd/ exists because there is a /proc/self symlink to /proc/<self-pid>/ not necessarily because it's useful for a process to open its own descriptors this way. Other /proc/self things are useful, like /proc/self/exe to find out where your executable is located.

[tsimionescu]

I understand why it's useful to have access to another process' opened files.

I was wondering more why the Plan9 behavior would be useful - why you would want opening /proc/self/fd/<n> to give you a reference to the same file description instead of giving you a new file description. I assume opening /proc/<other-pid>/fd/<n> doesn't share file descriptions with the other process in Plan9 either, but maybe I'm assuming that wrongly as well.

[kazinator]

If opening the other process' entry shares the description, that means you're messing with its read/write pointer.

[tsimionescu]

I know, which is why I'm hoping that's not the case.

But then, if that's not the case for /proc/<other>/fd/<n>, why would it be for /proc/self/fd/<n> ? Where does this expectation come from?

[DSMan195276]

> But what would be the use case of re-opening your own files in this way, that dup() doesn't cover?

Well you can't `dup()` an fd that you don't already have, this would let you do it. Assuming I understand the behavior right it doesn't have to be the original program calling `open()`.

If you're running a separate process and trying to debug another process that's running by peeking at its fds, then being able to just `open()` them is easier and less invasive compared to the alternatives for getting a dup'd fd (Ex. force the program to call `dup()` itself and then send the fd over a socket or something).

[nrdvana]

Usually to make a program do something the author didn't think of, by passing it a filename to one of its descriptors where the author only gave you a configuration of a path. For example, starting a service under a monitoring system which gives it a pipe to a logger on fd3, then telling it to write a log file of /dev/fd/3