What a filename deletion actually removes
A file on a Unix-style filesystem is represented by two related pieces: a directory entry, which connects a human-readable name to the file, and an inode, which stores metadata and points to the file’s data blocks. Deleting a filename usually removes that directory entry; it does not immediately scrub the contents of the data blocks.
If the inode still exists but no directory entry points to it, the file is called an orphaned inode. The bytes may remain on the drive, but the ordinary path used to find them is gone.
Why the space can stay occupied
Filesystems track which data blocks are available for reuse. When a file is properly unlinked and no process still has it open, the filesystem can release its inode and mark its blocks as free. But an interrupted operation, filesystem error, or crash can leave the bookkeeping out of sync: the name is gone, while the inode or its allocation records still claim space.
That mismatch is why a directory can appear to contain less data than the disk is actually using. The orphan is not necessarily recoverable as a normal file; its name and directory location may be lost, and later writes can overwrite its data.
How repair tools resolve the mismatch
A filesystem checker examines those records and compares them with the directory structure. If it finds an inode that has no valid directory entry, it can either reconnect it—often under a recovery directory—or mark its resources as available again. The exact action depends on the filesystem and the damage.
Until repair, the space may remain unavailable to new files. Once the checker releases those blocks, the drive can reuse them, even though that does not necessarily mean the old data has been securely erased.
