Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.misc
Subject: Re: File Recovery on an 80 MB partition
Keywords: File, HD
Message-ID: <19122@cbmvax.commodore.com>
Date: 19 Feb 91 21:14:14 GMT
References: <1276@swrinde.nde.swri.edu>
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 33

In article <1276@swrinde.nde.swri.edu> kent@swrinde.nde.swri.edu (Kent D. Polk) writes:

>Question: is there a utility (like the old Diskzap) that can work on an
>80 MB partition? 

I use DiskX for DiskSalv development.  It can edit tracks on any FFS or SFS
disk I have tried to date. 

>If so, can I follow a thread & designate it to be moved to a new file - fsdb 
>fashion? Or any fashion really? I can even get by with most of the data. 

Problem is, the only thread under FFS is in the file header.  Well, not all
true.  The first 36K or so of a file is referenced by pointers in the file
header.  The next 36K will be referenced by a file extension block, which in
turn points to the next file extension block, and so on.  Since you wrote over
the existing file, the current header should be on the same block the old one
was on.  You might be able to find an the first extension block referencing
that header block, assuming the OS hasn't overwritten it.  That will lead you,
by subsequent extension block pointers, to the next extension block, and so
on.  I don't know of any easy way to get DiskX to do this; you can imagine 
what the "difficult" way involves.

I have been thinking of doing something with loose extension blocks in future
versions of DiskSalv.  Well, perhaps a little more than just thinking about
it....

>Kent Polk: Southwest Research Institute (512) 522-2882


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"What works for me might work for you"	-Jimmy Buffett