kent@swrinde.nde.swri.edu (Kent D. Polk) (02/14/91)
A co-worker accidentally overwrote two files with tiny ones with the
same names. Needless to say, I need the originals. The data can't be
regenerated due to a physical change in the device which produced the
event data. (ok... so non-destructive examinations aren't always
completely non-destructive :^).
The originals are waveform files about 4 MB long and the new files are
about .5 MB. (Pete Goodeve: I know... it's being fixed - will be using
the ASL filerequester! - BTW, any comments?)
I ran DiskSalv, but I guess the file headers got trashed, since no
duplicate filenames corresponding to the ones I wanted were retrieved.
Each waveform event has a repeatable header that I could recognise if I
saw it.
Question: is there a utility (like the old Diskzap) that can work on an
80 MB partition? 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.
re backups: Yes we backup. No, the files weren't on the backup since
they were overwritten about a minute after they were closed :^(
Thanks much,
Kent Polk: Southwest Research Institute (512) 522-2882
Internet : kent@swrinde.nde.swri.edu
UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kentdaveh@cbmvax.commodore.com (Dave Haynie) (02/20/91)
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
kent@swrinde.nde.swri.edu (Kent D. Polk) (02/20/91)
In article <19122@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >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 [...] >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. We pulled up DiskX 2.2 (Steve Tibbett) and located about 400 of the desired blocks so far - by hand. DiskX can copy, block-by-block from one place to another, so we started trying to do so. Unfortunately, DiskX only knows how to save 488 byte blocks & gets confused when reading from 512 byte blocks. >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.... Believe me, it would be much appreciated. Back to the the task at hand: We are currently following two paths: a program to dump a list of block numbers (specified by a file), and one to dump a range of blocks to a file. Then a filter to search for the patterns and extract the data to another file. I would like to track the extension blocks, but either DiskX had trouble following them, or we did. (Still have 3MB more to go too). Right now we are trying to figure out how to 'convert' a trackdisk test program to work with the 2091. Hopefully will have something working soon. BTW, where is this stuff documented? I've gotten bits and pieces from AmigaMail, RKM's, examples on Fish Disks. Can we just substitute the device, unit num, etc. and use "trackdisk" calls? Do you happen to have: 1) an example of how to find the device & unit number from the system lists, given a partition name...? I know how to determine the numbers by hand - just wanted to specify the partition name to make it a bit more general. 2) an example of tracking the extension blocks (given a known one)? (though I think we have this one pretty much figured out) -------------------------------------- This has been a very educational experience. Provided one of those golden opportunities to learn some of this stuff :^( "Warming up for gpib.device" Polk Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent