Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: Need Undelete program (PANIC!!)
Message-ID: <9210@cbmvax.commodore.com>
Date: 4 Jan 90 17:42:02 GMT
References: <9001030607.AA27938@jade.berkeley.edu>
Organization: Commodore, West Chester, PA
Lines: 44

in article <9001030607.AA27938@jade.berkeley.edu>, GORRIEDE@UREGINA1.BITNET (Dennis Robert Gorrie) says:

> disksalv from dh0: to ram: quick start 140000 stop 170000 ask

> My drive has one big partition with about 300000 blocks.  On this FFS partition
> the ROOT area of the disk contains all of the directory blocks.  This is the
> area 140000 to 170000.  On your 42 meg drive, if you have a 42 meg partition,
> this would be about 30000 to 50000 on an FFS partiton.

The latest DiskSalv (V1.42) extends this a bit.  The START and STOP options now
take percentages as well as absolute block numbers or the word ROOT.  So, for
example, you might say something like:

DiskSalv from dh0: to ram: quick start 40% stop 60% ask

to get the center of the disk, where you'll find most directory and file headers.
As mentioned before, this version also knows the FILE keyword.  You could type:

DiskSalv from dh0: to ram: quick start 40% stop 60% ask file #?.(c|h)

for example, to only scan for C language files on the disk.  The file option 
only restricts file matching, not directory matching.  I put this in to make
DiskSalv more useful for undeleting things, since I found myself using it for
that.  It's still not really an undelete program, as undeleting with it is more
brute force than a good undelete program should be.  I plan to have a good 
undelete option in the next major release, but that probably won't be ready
until some time in the Spring.

> I wish DiskSalv could do this process of hunting out the DirBlocks automaticaly
> instead of having people search for them by trial and error.

I'm thinking about what to do with a directory pattern.  With the file pattern,
it's really easy, and it also restricts the scan and the memory required, since
I can accept or reject a file based on the name alone.  With a directory search,
I would either have to accept every directory and then filter out the ones that
don't match when the scan is over, or reject those that don't match, then go
back and recursively get all the parents of those matched directories.  I'll 
probably have such a feature in version 2, whenever it gets done.

> |Dennis Gorrie                 'Sudden de-compression Sucks!'           |
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough