🫩🫩🫩🫩

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 1 year ago (3 children)

Hmm. So are the blocks freed up for overwriting on file close, then?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 1 year ago* (last edited 1 year ago) (2 children)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 year ago (1 child)

    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?

  • source
  • parent
  • hideshow 1 child comment
  • 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.

  • source
  • parent