Some senseless babbling from Jonathan De Boyne Pollard to Mike Ruskai
on 11-08-99  09:40 about Multiple primary HPFS...

 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?

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

Sure, but as most people run an undelete program shortly after accidentally
deleting that which is not backed up, and don't close anything that might
write to the disk, wouldn't it be worth checking for such situations in an
undelete program?

That is, is there any reason not to look at all space, regardless of
whether or not it's marked as in use?

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

I would take the same route as GammaTech's undelete program, by not writing
anything at all to the drive in question, but merely reading from it, and
writing undeleted files to a separate drive.

That would make locking the drive unnecessary, which also makes it possible
to function on a drive that can't be locked (such as the boot drive).

Mike Ruskai
thannymeister@yahoo.com


... A cat will always sit on whatever it is you're trying to read or copy.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2