The creator of this image is Julia Evans. She's awesome. She's also really active on Mastodon @b0rk@jvns.ca and has a bot that posts a bunch of images similar to this one @b0rk_reruns@jvns.ca. 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 Comments
Unleaded8163@fedia.io · 50 pts · 14d
The creator of this image is Julia Evans. She's awesome. She's also really active on Mastodon @b0rk@jvns.ca and has a bot that posts a bunch of images similar to this one @b0rk_reruns@jvns.ca. 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.
rimu@piefed.social · 1 pts · 13d
Thank you!
state_electrician@discuss.tchncs.de · 21 pts · 14d
/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.
sik0fewl@piefed.ca · 8 pts · 14d
How can the symlinks work if the file has been deleted?
princess@lemmy.blahaj.zone · 13 pts · 14d
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 systemtrem@lemmy.blahaj.zone · 11 pts · 14d
Just 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.
korthrun@piefed.social · 7 pts · 14d
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.txtsik0fewl@piefed.ca · 5 pts · 14d
Ya, 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.
Novocirab@feddit.org · 5 pts · 14d
Superb, thank you for sharing!!