What happens during an unlink(2)

[Edward C. Bennett]

In article <979 at kitty.UUCP>, larry at kitty.UUCP writes:
>In article <403 at ukecc.UUCP>, edward at ukecc.UUCP (Edward C. Bennett) writes:
>>
>>       But you can recover an unlinked file! I know, I've had to do it.
>> You must unmount the file system and search the free list for your data.
>> It's a PITA, but worth it if you lose something big.
>
>        I don't claim to be a UNIX internals expert (I have enough trouble
> writing I/O drivers :-) ), but don't most ports of UNIX zero disk blocks after
> an unlink(2)?  As I seem to recall, unlink(2) is derived from unlink.s, which
> is assembly language specific for the given machine.  And unlink.s contains
> a routine _unlink which fills the disk blocks with .word defined as 0x0000.

        When you unlink a file, the disk block addresses in the inode are
zeroed, not the actual data blocks. Zeroing the inode is tantamount to
'forgetting' where the data is actually stored. The 'forgotten' data
blocks are added to the (top of the) free list to be used when adding data
to the filesystem.
        When the old data blocks are placed in the free list, their contents
are unimportant. Zeroing the blocks would be a waste of time since whatever
is there will be overwritten when the blocks are allocated to another file.
This situation is identical to the malloc()/free() process. i.e. Space
that has been malloc()ed will have data written into it. When this space
is free()ed, the data in it is not altered and is useable until the next
malloc().

--
Edward C. Bennett

UUCP: ihnp4!cbosgd!ukma!ukecc!edward

Kentucky: The state that is being dragged, kicking and screaming,
          into the 20th century.

"Goodnight M.A."