blgardne@esunix.UUCP (Blaine Gardner) (11/10/88)
From article <1070@esunix.UUCP>, by blgardne@esunix.UUCP (Blaine Gardner): > [Will someone remove all sharp objects from the room so I don't injure > myself?] [Description of some twit deleting the only copy of his S-S edited.] > Ok, move onto DiskSalv then. But after running disksalv there is no > trace of the deleted file. No writes were done the hard drive after my > screwup (in fact I used the LOCK command to make sure!), but the file is > not there. Am I correct in assuming that some of the redundancy of the > OFS was traded for the speed of the FFS? Patience IS a virture. But it's hard to remember that when you think you've killed your system. I had been trying DiskSalv 1.3 with the START and STOP options to avoid scanning the whole 34 meg partition. The ranges I used weren't big enough I guess, because it was unable to recover my deleted Startup- Sequence. However, when I let it run on the whole partition, it did successfully recover the deleted file. [Insert boundless praise for Dave Haynie here.] DiskSalv really saved my hide here, thanks Dave! One possible tiny bug though. I was running the salvage from one 34M partition to a directory on my second 34M partition. After ~880K it told me that the disk was full, and to insert another. (This is with about 28M free on the destination partition.) I aborted the salvage, and retried with the NOCHECK option, and it worked fine. The docs say you need to use NOCHECK if RAM: is the destination (because of RAM:'s constant 0% free status). But shouldn't DiskSalv check to see how much space is REALLY there, instead of assuming 880K? > It looks like daily backups from here on out. Still a good idea I think! -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 Here: utah-cs!esunix!blgardne {ucbvax,allegra,decvax}!decwrl!esunix!blgardne There: uunet!iconsys!caeco!pedro!worsel!blaine (under construction) "Nobody will ever need more than 64K." "Nobody needs multitasking on a PC."
daveh@cbmvax.UUCP (Dave Haynie) (11/15/88)
in article <1072@esunix.UUCP>, blgardne@esunix.UUCP (Blaine Gardner) says: > DiskSalv really saved my hide here, thanks Dave! One possible tiny bug > though. I was running the salvage from one 34M partition to a directory > on my second 34M partition. After ~880K it told me that the disk was > full, and to insert another. (This is with about 28M free on the > destination partition.) I aborted the salvage, and retried with the > NOCHECK option, and it worked fine. What you've run into is one of those oddities I mentioned in my previous posting. DiskSalv does actually check the size of the output device. When you're recovering a file, it checks the size of the file against the size of the output device. If the file won't fit, you get that DISK FULL message, and you'll keep getting it until you give it a disk that'll fit that file plus it's directory level. This is all well and good, expect that I found, so far on FFS partitions only, that the file size (I was using the file header entry that told me how many blocks were in the file, as that's what DiskSalv cares about) on files is occasionally wrong. Sometimes very wrong. These may just be deleted files, by they can really confuse DS V1.3. I have a new version almost ready for release that does the following: - Uses some redundancy information in a file header to try and figure out the real size of the file. - Does bounds checking to reject impossible file sizes. - Checks extension block information to further back up it's estimation of file size. - If all else fails, the DISK FULL message now tells you how many blocks are free on the disk and how many it thinks the file needs. You have the option to skip that file or ignore the warning as well as changing your output size. > The docs say you need to use NOCHECK if RAM: is the destination (because > of RAM:'s constant 0% free status). But shouldn't DiskSalv check to see > how much space is REALLY there, instead of assuming 880K? As I said, it really does. NOCHECK is supposed to be set automatically when RAM: is given as output, but that was also slightly damaged in V1.3, and is now fixed. > Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession