You can also still access the file as long as there’s a process that still has it open. I have, in the past, “undeleted” a file or two doing that.
$ echo foo > bar
$ tail -f bar
foo
In another terminal:
$ pidof tail
1525534
$ ls -l /proc/1525534/fd|grep bar
lr-x------ 1 tal tal 64 Jun 16 06:42 3 -> /home/tal/bar
$ rm bar
$ ls -l /proc/1525534/fd|grep bar
lr-x------ 1 tal tal 64 Jun 16 06:42 3 -> /home/tal/bar (deleted)
$ cat /proc/1525534/fd/3
foo
$ cat /proc/1525534/fd/3 > bar-recovered
$ cat bar-recovered
foo
$
That is, the /proc entry for tail’s file descriptor 3 there looks kinda like a symlink, but the kernel doesn’t actually make it behave in quite the same way as a normal symlink.
That being said, getting back to the original point about unlinking not being able to remove the directory entry…it won’t sit there blocking you from putting a new directory entry there with the same name, the way Windows file semantics mandate.
EDIT: Also, what rm removes is the directory entry rather than the inode. The inode sticks around as long as the file data is there. You can have multiple directory entries for an inode, or none at all, but file data will have an inode associated with it.
$ touch a
$ sudo ln -T a b
$ stat -c %i a
216538023
$ stat -c %i b
216538023
An inode may have no links. An inode without links represents a file with no remaining directory entries or paths leading to it in the filesystem. A file that has been deleted or lacks directory entries pointing to it is termed an ‘unlinked’ file.
Such files are removed from the filesystem, freeing the occupied disk space for reuse. An inode without links remains in the filesystem until the resources (disk space and blocks) freed by the unlinked file are deallocated or the file system is modified.
Although an unlinked file becomes invisible in the filesystem, its deletion is deferred until all processes with access to the file have finished using it, including executable files which are implicitly held open by the processes executing them.
You can also still access the file as long as there’s a process that still has it open. I have, in the past, “undeleted” a file or two doing that.
In another terminal:
That is, the /proc entry for tail’s file descriptor 3 there looks kinda like a symlink, but the kernel doesn’t actually make it behave in quite the same way as a normal symlink.
That being said, getting back to the original point about unlinking not being able to remove the directory entry…it won’t sit there blocking you from putting a new directory entry there with the same name, the way Windows file semantics mandate.
EDIT: Also, what
rmremoves is the directory entry rather than the inode. The inode sticks around as long as the file data is there. You can have multiple directory entries for an inode, or none at all, but file data will have an inode associated with it.Same inode, different directory entries.
https://en.wikipedia.org/wiki/Inode