I've read the man pages on fork(), and they say something along the lines of "all file descriptors open in the calling process are copied".

It is not 100% clear to me if the file descriptor for the executable binary that the calling process is executing at that point in time is included in that statement. I know the man pages say "all file descriptors", but I'm asking this because it would seem easier to me to open() the same executable binary for the forked process, rather than synchronizing two processes working with them. So if they are indeed also copied, why?

  • 1
    A running program doesn't have an open file descriptor associated with the on-disk file that was used to run it. Nov 7 '20 at 18:48
  • THis question is very confused -- it looks as if the poster doesn't undesrstand the technical meaning of "file descriptor" at all.
    – q.undertow
    Nov 7 '20 at 18:50
  • @q.undertow can you elaborate how this is a misunderstanding in what a file descriptor technically is?
    – darthDoe
    Nov 7 '20 at 19:10
  • @darthDoe : essentially. a file descriptor is a reference to an already open file. So your stated goal of re-opening the executable doesn't make good sense.
    – q.undertow
    Nov 7 '20 at 19:41
  • from my understanding it is a reference to a file description, my point was to create a new fildes using the open() syscall instead of copying the existing fildes and therefor using the same file description in both processes. Obviously my basis was flawed, but I don't think that I understand file descriptors incorrectly
    – darthDoe
    Nov 7 '20 at 19:55

There's no file descriptor to the binary file being executed, only memory mappings.

(See, e.g. ls -l /proc/self/fd and cat /proc/self/maps on Linux.)

The memory mappings will point to the same file, of course, but that's what happens with shared libraries, too. In the case of the main program file, on Linux, writes to it while it's being used by a running process are not allowed. (Though the last time I checked, that didn't apply to shared libraries.)


It's unclear what you're actually trying to do, but on Linux (and some other systems) you can get a file descriptor to the current executable with open("/proc/self/exe", ...). That will work even if the file was removed or never existed in the filesystem.

Just like /dev/tty (which will always open the controlling tty of the calling process -- if any), /proc/self/exe will always open the file which the calling process is currently executing. They both act as "doors" to hidded open file descriptions already referenced by the process, allowing them to be accessed like normal files.

Those are hardly the only "hidden"/latent file descriptors a process has. In particular you can create a memory mapping of a file with mmap(..., fd, ...), and then closing fd will NOT remove that mapping, and your process will still hold a reference to that file, just like a file descriptor would (and on Linux, you can turn it back into a file descriptor by opening /proc/self/map_files/<range>).

Other examples are the root and current working directory (/proc/self/{cwd,root}) -- though, just as with any directories, even those referenced via open fds, their semantics are different than those of regular files -- in particular, you cannot create a file inside a removed directory, the way you can keep writing data to a removed file via its still opened file descriptor.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.