bard@jessica.stanford.edu (David Hopper) (04/02/91)
I've got a problem I hope someone can help me with (Dave? You out
there?).
On my 1-meg 500 I used to be able to use DiskSalv 1.42 just fine. Upon
upgrading to 1-meg of chip ram, however, DiskSalv chows on my memory.
Even using the LOMEM option, DiskSalv takes huge chunks of memory, until
the system locks up. Even CTRL-D'ing to the startup shell isn't enough
memory for it.
What's the problem? It worked fine with 512K of pseudo-fastmem.
What's an alternative Disk Salver for a 1-meg system?
Thanks so much,
Dave Hopper | /// Anthro Creep | Academic Info Resources, Stanford
|__ /// . . | Macincrap/UNIX Consultant
bard@jessica. |\\\/// Ia! Ia! | -- Just remember: love is life, and
Stanford.EDU | \XX/ Shub-Niggurath! | hate is living death. :Black Sabbathdaveh@cbmvax.commodore.com (Dave Haynie) (04/03/91)
In article <1991Apr2.015014.21151@leland.Stanford.EDU> bard@jessica.stanford.edu (David Hopper) writes: >On my 1-meg 500 I used to be able to use DiskSalv 1.42 just fine. Upon >upgrading to 1-meg of chip ram, however, DiskSalv chows on my memory. Are you sure that this is DiskSalv V1.42? Previous versions had a memory allocation bug that could cause memory allocations to fail for no good reason, depending on your configuration, available memory, phase of the moon, etc. I don't know of any such problems with V1.42, at least, I've never had such a problem reported before. Is this with all floppies, all disk devices, etc.? Perhaps a DOS device that specifies Fast memory, when all you have is chip? Or a specific floppy, that fools the program (this has been known to happen, but it has become much less frequent with V4.xx, since every time I get a floppy that makes the program fail, I release a fixed version). >Even using the LOMEM option, DiskSalv takes huge chunks of memory, until >the system locks up. LOMEM will cut down on memory usage, but it's no miracle. If DiskSalv, for whatever reason, thinks it needs more memory, it'll try to get it, and eventually fail when there's no more left. >What's an alternative Disk Salver for a 1-meg system? I can't say for sure than anyone else has had a problem with V1.42. I'll certainly try it on a plain 1MB ChipRAM system. The FixDisk program seems to be pretty reliable, at least on small partitions like floppies. >Dave Hopper | /// Anthro Creep | Academic Info Resources, Stanford -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
robtu@itx.isc.com (Rob Tulloh) (04/05/91)
Regarding disksalv 1.42, I recently used it to salvage a large hard disk partition (42MB) on my 100MB/2 hard disk A500. When it got to the salvage phase (or whatever it is called), I happened to notice that it linked one extended block with some huge number like 93479274923478 (that is not really the number, but it was something huge). This looks like a bad pointer that disksalv didn't catch/deal with. The file was a .zoo file which I had downloaded recently. I don't know how disksalv really dealt with this file since when I attempted to delete the original, sometimes the system complained that the disk was not validated and other times it guru'ed attempting to delete it. I had a power hit on the machine while running backups and when I powered back on, I got a checksum error on DH0:. Faced with this dilemma, I fired up disksalv and noticed the huge block number when it salvaged that particular file. I was able to delete the salvaged file. Is this a bug? Disksalv seemed to work OK, I was able to delete the restored file and it restored everything else quite neatly. I zapped the original hard disk partition and reloaded it with the copied files and all has been peachy since (no checksum errors or validation problems). Just thought I would mention the huge number to see if it was anything that should/could be fixed. Rob Tulloh -- INTERACTIVE Systems Corp. Tel: (512) 343 0376 Ext. 116 9442 Capital of Texas Hwy. North Fax: (512) 343 0376 Ext. 161 (not a typo!) Arboretum Plaza One, Suite 700 Net: robertt@isc.com (polled daily) Austin, Texas 78759 GEnie: R.TULLOH (polled monthly)