Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: AmigaDOS and DiskSalv 1.32 Problem
Message-ID: <7159@cbmvax.UUCP>
Date: 28 Jun 89 18:40:04 GMT
References: <2980@wpi.wpi.edu>
Distribution: usa
Organization: Commodore Technology, West Chester, PA
Lines: 56

in article <2980@wpi.wpi.edu>, john@wpi.wpi.edu (John F Stoffel) says:
> Keywords: DiskSalv 1.32, AmigaDOS, HELP, BIG problem

> Well, it seems i have found a bug in DiskSalv 1.32, but maybe this is
> a bug of the Workbench, so i ask u all to take a blank formatted disk,
> and follow theese steps:
> 1. [...] 9. And now let us be cruel 8). Drag the Empty-drawer into the 
>             'copy of Empty'-Window, and drag the 'copy of Empty'-drawer 
>             into the Empty-Window. Got it? Cruel isn't it? 8)

So Workbench lets you cross link directories, eh?  Sounds like one bug 
there that's not mine, but onward...

> But! Don't use Disksalv 1.32 on a disk like that!!!! [...] ...and DiskSalv 
> begun it's work, not knowing that somewhere on this disk a little trap was 
> waiting for it. As it approached the directory-structure it didn't find a 
> way out of this labyrinth of drawers and presented me a guru-party.

Yup, that's just what's happening.  DiskSalv V1.32 will try to walk the 
directory tree to print the directory name during recovery (also to get
the names of directories to create).  Any kind of directory loops will be
tragic, as the string will just grow and grow, with accompanying function
recursions, until you crash.

> Is this a way to protect disks from being salvaged? (good idea it seems)

No longer...

> Is this a bug of DiskSalv or AmigaDos? (the guru, not the disapearing drawers)

The Guru is DiskSalv's.  Fortunately, this is fixed in DiskSalv V1.40.  The
fix was rather simple.  When DiskSalv finds a file or directory, it checks 
it's internal tree for the existence of that item's directory.  If there isn't
a directory for it yet, you get an entry in the LOOSE-BLOCKS directory.  As
the scanning proceeds, more directories may be found, and if so, they're
moved from the LOOSE-BLOCKS directory to where they belong.  Only now, before
inserting a directory anywhere, I check to make sure that it's not referenced
as a parent of it's intended parent directory.  If it is, it'll have it's name
updated, but it'll still be kept in the LOOSE-BLOCKS directory.  In the event
of self-referential directories, one will wind up as a child of the other, based
on the order they're found on disk, but the looping will be eliminated.

> Any suggestions, reports, flames are welcome.
> If someone can reach Dave Haynie (..!cbmvax!daveh or BIX: hazy), please
> report this bug.

Thanks anyway for the bug report.  Someone beat you to it, but actually had
to send me a disk to examine; you've apparently found a reliable (least till
1.4) way to create such loops that I didn't know about.

> | Peter/_/_|Marquardt | uucp - uucp: ..!unido!altger!hermann.UUCP       |

-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
           Be careful what you wish for -- you just might get it