The creator of this image is Julia Evans. She's awesome. She's also really active on Mastodon @[email protected] and has a bot that posts a bunch of images similar to this one @[email protected]. She also sells bigger, more in-depth zines at wizardzines.com. I don't know her personally, just think she's great. Both of those mastodon accounts are worth following IMO.
/proc is one of the things I keep learning about again and again. I always read about it when I don't need it and when I would need it, I have forgotten about it.
They aren't symbolic links. They're closer to hard links, IIRC, in that they share the inode with other file paths.
ofc /proc isn't a "real" file system so the metaphors break down a little; it's not backed by disk, it's a view into the kernel's process information exposed as a file system
ls -l does not show them like hard links, but rather like soft/symbolic links.
But when I do tail -f /path/to/file.txt on a file (to keep it open in a process) and then delete the file, I get this output in ls -l:
3 -> '/path/to/file.txt (deleted)'
The 3 seems to just be an incrementing number for each file opened by the process. And then, well, obviously the file isn't now called "file.txt (deleted)". That is just a name the kernel makes up when ls -l asks it what's in that directory.
So, presumably the kernel keeps a separate copy of that file in memory until the process closes the file or is terminated. And then exposes it through this pseudo-softlink rather than making use of hardlinks.
If you throw an strace on a process that interacts with the filesystem you'll see that stuff like open() returns a file descriptor and stuff like read() takes a file descriptor as an argument.
These are also generally the numbers you're using when you do I/O redirection in your shell with stuff like 2>&1 or exec 5< ./some_file.txt
9 replies
The creator of this image is Julia Evans. She's awesome. She's also really active on Mastodon @[email protected] and has a bot that posts a bunch of images similar to this one @[email protected]. She also sells bigger, more in-depth zines at wizardzines.com. I don't know her personally, just think she's great. Both of those mastodon accounts are worth following IMO.
Thank you!
/proc is one of the things I keep learning about again and again. I always read about it when I don't need it and when I would need it, I have forgotten about it.
How can the symlinks work if the file has been deleted?
They aren't symbolic links. They're closer to hard links, IIRC, in that they share the inode with other file paths.
ofc
/procisn't a "real" file system so the metaphors break down a little; it's not backed by disk, it's a view into the kernel's process information exposed as a file systemJust to kind of confirm this:
ls -ldoes not show them like hard links, but rather like soft/symbolic links.But when I do
tail -f /path/to/file.txton a file (to keep it open in a process) and then delete the file, I get this output inls -l:The
3seems to just be an incrementing number for each file opened by the process. And then, well, obviously the file isn't now called "file.txt (deleted)". That is just a name the kernel makes up whenls -lasks it what's in that directory.So, presumably the kernel keeps a separate copy of that file in memory until the process closes the file or is terminated. And then exposes it through this pseudo-softlink rather than making use of hardlinks.
FWIW: https://en.wikipedia.org/wiki/File_descriptor#file_descriptor_table
If you throw an
straceon a process that interacts with the filesystem you'll see that stuff likeopen()returns a file descriptor and stuff likeread()takes a file descriptor as an argument.These are also generally the numbers you're using when you do I/O redirection in your shell with stuff like
2>&1orexec 5< ./some_file.txtYa, the description sounds more like a hard link, but that also doesn’t work, since the executable is obviously not stored on /proc.
Your explanation makes sense, thanks.
Superb, thank you for sharing!!