MR> It does stand to reason that any FNode which resides in a sector
 MR> marked free is a deleted file, that could potentially be recovered. 
 MR> What about FNodes that happen to reside in the reserved but as-yet
 MR> unused sectors of a file?  That is, when a file is created with some
 MR> slack space to grow into, it's slack space will be marked used, but
 MR> not written to yet.  Could there not be an FNode, or even file data,
 MR> in that slack space which can be recovered?

This situation only ocurrs when a file is in an intermediate state.  The slack 
claimed space beyond the end of the file will be released when (the last open
handle to) the file is closed.  If this were not done, the on-disc state would 
be inconsistent.  (Also, programs that guessed wrong as to the sizes of files
that they need would cause a great deal of space to be wasted unnecessarily.)  
CHKDSK treats the case where the allocated space exceeds the file length given 
in the FNode as an error, and corrects it.

If you are looking directly at the disc data, then it follows that no open
file handles exist for files on the volume that you are writing to, since you
will have locked the volume.  It thus follows that no file should be in that
particular intermediate state.  If a file *is* in such a state, then be aware
that there was probably a dirty shutdown and that the volume data may thus be
inconsistent elsewhere as well.  Tread carefully.  You don't really want to
write *any* new data (such as new directory entries for files that you have
undeleted, for example) to that volume before running CHKDSK to make the
on-disc structures self-consistent again.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR