Yep, it’s a smart system.
For the user, the file is immediately no longer in the tree, so for them it’s considered done.
The OS should handle all the hassle, not the user.

I think “consider it done” puts it well.

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

Same inode, different directory entries.

https://en.wikipedia.org/wiki/Inode

inode persistence and unlinked files

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.

Do modern file systems actually remove it from disk? It’s been a while since I did any forensics and didn’t do much of it, but I remember being able to batch restore files from inodes as long as that part of the disk hadn’t been overwritten. That’s why you’re supposed to overwrite disks with random data if you want to data gone.

Interesting TIL

You almost always want to pair lsof with -n, as by default, it (slowly) lists a bunch of things that require name resolution.

$ time lsof >/dev/null

real    2m12.352s
user    0m0.499s
sys     0m1.217s
$ time lsof -n >/dev/null

real    0m1.600s
user    0m0.523s
sys     0m1.029s
$

You can lazy umount, which blocks new accesses and actually unmounts when it can

Btw this also method to prevent file/dir be automatic created: for dir make file with same name, for file other way.

Usually rename only replace other file, not dir. And if path exist but file, cannot open as dir, but also not create.

I imagine it more as a condescending IT guy who isn’t actually very good at his job and has secretly set up each machine to spy on the users (but again isn’t very good at what he does so it isn’t much of a secret).

I imagine it as more surly and petulant.

No, that’s macOS

Where did I read that the þ character doesn’t really help against AI at this point? That it is pretty futile? Can’t remember.