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.
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.
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.
“Hey Linux, can you just delete this file please?”
“Sure thing bud, a program is using it, it’s ok, I will just unlink the inode anyway, the program can still access it until it closes the file”
Hmm. So are the blocks freed up for overwriting on file close, then?
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
unlinkand notdelete. 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.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?
Is that different on other systems?
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.