Yes. On Linux/Unix you don't delete the file, you just delete it's name, which is merely a link to the actual file. That's also the reason why the syscalls name is actually unlink and not delete. As soon as there's nothing pointing to a file anymore, it is deleted.

As long as a process holds a file handle, there's still a reference to said file, so it won't be deleted. That saved me once, when I accidentally deleted a file I wanted to keep: As there still was some process keeping it alive, I could just go to /proc/[process id]/fd/[file descriptor id] and copy it to a safe location.

[–] CanadaPlus@lemmy.sdf.org 1 points 3 weeks ago (1 children)

Good to know, and helps me understand code dealing with filesystems a little better. I'm curious how the kernel keeps track of it all, just a counter maybe?

On Linux/Unix you don’t delete the file, you just delete it’s name, which is merely a link to the actual file.

Is that different on other systems?

[–] brotundspiele@sh.itjust.works 2 points 3 weeks ago

I don't know how NTFS does it, but on FAT filesystems the directory table contains the filename along with all the other file metadata (access rights, creation date, size, etc). Only the list of sectors containing the actual data is separate. That means that you can't have two filenames for the same file on FAT filesystems.

If you want to learn more about this, the data structure UNIX filesystems use, and FAT filesystems lack is called inode.