This is not a SFW instance. NSFW communities will be tagged, and efforts will be made to keep SFW communities clean, but proceed at your own comfort level.
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
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:3 -> '/path/to/file.txt (deleted)'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.