bob@nbires.UUCP (Bob Bruck) (07/19/85)
Daniel Gray wrote: > The FAT (File Allocation Table) contains smaller structures within it > that are sometimes refered to as FCBs (File Control Blocks). The table > or control block is simply an index to the beginning of the file and > also contains the number of records that the file contains. When a file > is erase, the FCB -or- FAT is flagged that this entry is now availible > for use. Now I am really getting confused! I thought that the directory information on the disk contained the location of the first allocation block for the file described by that directory entry. Once you know the first allocation block, you can use the FAT as a linked list to find subsequent allocation blocks. I assumed (probably incorrectly) that when a file is deleted, each FAT entry in this linked list is set to zero (000) to indicate that this cluster is unused and available. If this linked list is destroyed in this way, then the file would be unrecoverable (I think). On the other hand, if this assumption is incorrect, then DOS must at some point do "garbage collection" to recover space used by deleted files. Can anyone out there in NETland (Microsoft, are you listening?) clear up my confusion about this? Thanks. Bob Bruck NBI, Inc. Boulder, Co. (hao | allegra | ...)!nbires!bob
abm@ptsfa.UUCP (Al Margolis) (07/19/85)
> Although I don't know of a specific product for the > IBM PC that actually delete the file contents > when "deleting" a file, it definitely is possible. Almost every encryption program I have seen for the PC comes with a zapper program to this, to obliterate the plain-text file. You should be able to locate a package for < $50. You could write your own fairly simply ... just open the file random, check its size, then overwrite garbage; when you delete the file normally, only garbage is returned to the free space pool. My personal opinion is that if you are truly concerned about security under MSDOS you should get another operating system. If you are stuborn (sp?), like me, you have to start with good physical security, add an access control package that never lets you leave the door very open, and pray a lot. I have been playing with Watchdog by Fischer-Innis, and it looks pretty unbreakable -- has anybody else had any experience. Al Margolis Pacific Bell {dual, ihnp4} !ptsfa!abm *** I'm not associated with Fischer-Innis *** *** The opinions expressed are my own... ***
slerner@sesame.UUCP (Simcha-Yitzchak Lerner) (07/23/85)
> Now I am really getting confused! I thought that the directory information > on the disk contained the location of the first allocation block for the > file described by that directory entry. Once you know the first allocation > block, you can use the FAT as a linked list to find subsequent allocation > blocks. I assumed (probably incorrectly) that when a file is deleted, each > FAT entry in this linked list is set to zero (000) to indicate that this > cluster is unused and available. If this linked list is destroyed in this > way, then the file would be unrecoverable (I think). On the other hand, if > this assumption is incorrect, then DOS must at some point do "garbage > collection" to recover space used by deleted files. > > Can anyone out there in NETland (Microsoft, are you listening?) clear up my > confusion about this? Thanks. > To clarify, your assumptions are correct. The directory entry does point to the first entry in the fat. when a file is erased, the first letter of the file name is overwritten with E0h and the entire linked list in the fat for the file is zeroed. When dos needs new space, it scans the fat sequentialy for zeroed out entries. There is no list or pointer to available space. (I think to many cp/m hackers have been putting in their $.02 and confusing things.) by the way, a fat entry points to a cluster, not a sector. a cluster is a group of sectors, # of sectors per cluster dependent on volume type. (SS floppy has 1 to 1 correspondence) Hope this has clarified the issue. **sigh** -- Opinions expressed are public domain, and do not belong to Lotus Development Corp. ---------------------------------------------------------------- Simcha-Yitzchak Lerner {genrad|ihnp4|ima}!wjh12!talcott!sesame!slerner {cbosgd|harvard}!talcott!sesame!slerner slerner%sesame@harvard.ARPA