In fact, there is a different explanation for the mark as deleted
approach. Depending on how it's handled, it can even make the undeletion
explanation untenable.
The point of "mark as deleted" was, at least originally, a matter of
*SPEED*. MS-DOS would mark a file as deleted in the directory, as well as
marking the space occupied by the file as free in the FAT tables, rather
than taking the time to actually over-write the empty spaces immediately.
When a new file was created in that subdirectory, after a reboot, the
system would scan the subdirectory file and use the first directory entry
marked as deleted for the new file directory entry. Likewise, the FAT
table would be scanned for placed marked empty - whether they'd ever been
written to, or not. This is why, over time, a defragmentation process was
a good thing - it reduced the fragmentation caused by this process,
allowing files to be read faster with less head movement.
Likewise, in the MBOX format that many if not most mail programs use,
simply marking an e-mail as deleted is much faster than the complete
re-writing of the file that would be necessary for full deletion. That it
allows for undeletion is a happy accident, it was not the design goal.
Compaction allows for the multiple re-writes of the entire MBOX file to be
done as one long re-write, skipping over e-mails marked deleted.
This is even seen in database engines with fixed-size records - mark a
record deleted, and when it's time to insert a new record, use the space
from an old deleted record to store the new one.
--
Jamey
----<--<@
[email protected]
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
