Linux

lsof just reads from /proc and gives you formatted output

https://github.com/lsof-org/lsof/blob/master/lib/dialects/linux/dproc.c#L297

Wait until you see the Plan 9 API

I bet this is done with inodes. Deleted files aren't truely deleted until nothing has it open and its inode gets dropped. Like ARC for files.

You can also do interesting things like overwrite a "file" (as in a specific filesystem path) with new contents while keeping anything that already has the file open on the old contents by unlinking the old inode to the path and writing the new contents under a new inode. I believe mv does this. The kind of lesser known feature that probably strikes a good balance between preventing super annoying silent errors/corruption and causing them.

Relevant Kevin Fang video

It's a bit more interesting than that...

Linux, unlike Windows, will let you delete a file that is actively in use. It removes the reference on the file system but the contents of the file won't be deleted until all file pointers to it close. In fact it will still be seen as taking up disk space until it's garbage collected (deleting a large file that's in use can be frustrating).

So the file is actually still available to that running process. If you replace it with a new executable and run that then you get the new version.

they are a youtuber?

I may have been through "SysFS" as well? In /sys/class you can setup char dev IO with a kernel module (and more). Very helpful for userspace <-> kernel communication (like DMA drivers for userspace applications)

I no no idea you liked this, nice

THERE'S MORE?

https://jvns.ca/

Also known as zombie files. If you are unlucky they can take up all space on a drive, or even tmpfs (so your ram) and you can't easily find them. At least until you end the right process or restart.
Had that happen once and had to write my own script to trace it to the log of an open terminal emulator tab that had billions of lines.

A symlink that has been blessed by Richard Stallman.

If you delete a file that's still open by the app, the link in proc will still exist and you can copy the file back out of proc.

That raises the question of how their ps, top, lsof and such work, since afaik in Linux they read from /proc.

P.S. Looks like BSDs tug at the kernel via syscalls, namely sysctl and also the ‘kvm interface’ in the case of MacOS (not sure what ‘kvm’ thing is meant here). Seems vaguely reasonable, since procfs also queries the kernel for the info, so about the same resources would be used, perhaps even with the overhead of filesystem traversal and string-numbers conversion.

I would generally just set the RPATH to $ORIGIN in the ELF file