A determined effort

Copyright Dr Alan Solomon (1986-1995)

Most people come to me when they have a major problem, which happened
through no fault of their own.  Simon was a slightly different case.

Simon called me because he had deleted a major database.  He ran
Norton, but when a file is large and fragmented, no automatic program
will bring it back, as it doesn't know where on the disk to find the
pieces.  It's a time consuming and fiddly job putting something like
that back together, so I quoted Simon a three figure sum, and I could
hear his sharp intake of breath.  "That's a bit steep", he said.  "Yes
indeed", I said, "And I'm sorry you've accidentally deleted your
database, but it'll take me a long time to do.  I work no-fix, no-fee,
so all you have to decide is whether your particular database is worth
me salvaging for you." "I think I'll have another go myself", said

He called back in a few hours.  "I think I'll take you up on your
offer", he said.  "Hang on a bit - what have you done since we last
spoke?", I asked.  It turned out that Simon had deleted the entire
subdirectory, and removed the subdirectory, and now he was finding
that he couldn't even get the subdirectory to list.  "Sorry," I said,
"It sounds like more work than before" and I put the price up by #100.
Simon was surprised, and hurt.  "You said ..." he complained.  "Yes
indeed, I quoted for a job, but the job is different now."

Simon decided it was too unfair, and he would have another go.  This
time he formatted the disk, and then used Mace to unformat it.  You
can sort of see why he thought it might work, and you can see why it
couldn't possibly.  The problem was still the same - the database was
fragmented, so the automatic program couldn't find all the pieces.
Only now, all the other fragmented files on the disk were equally

Simon called me again, I added another #100 to my quote, and he rang
off in disgust.  This time, he reformatted the disk, reinstalled DOS,
copied all the DOS utilities back on, ran Mace and to no-one's
surprise, that didn't get his database back either.  Copying on the
DOS utilities would have overwritten the subdirectory information that
hadn't been destroyed up till now, so when he called me back again, I
added another #100 to the price.  Simon couldn't believe that he
couldn't do it himself, only now he'd run out of things to try.  Or so
I though.  Simon had one more trick left up his sleeve - he did a low
level format of the disk, but as he knew that this would irreversibly
wipe everything out, he was clever.  He listened to the disk, waited
until he'd heard the motor step once, and then switched power off.
Then he ran Fdisk, but Fdisk said that the disk was damaged, and
refused to run.  Norton reported no drive C, Mace said no hard disk,
File Rescue Plus offered to repair a floppy disk but no hard disk, and
Simon had run out of options.

When he called me, I added yet another #100 to the quote.  Simon
seemed to be somewhat dazed, and meekly accepted the fact that as he'd
just made the job harder yet again, it was reasonable to up the price.
At this point, he revealed why it was so important - it wasn't his
disk, and without going into details, something terrible would happen
to him if I couldn't get that data back.  I resisted the urge to shout
at him, or to point out that he'd turned a straight forward but
time-consuming job into a major challenge.  I refrained from telling
him what I thought about his common sense, and restricted myself to
telling him that I wouldn't be able to get everything he'd lost.  The
problem was, by re-copying DOS onto the disk, he'd overwritten quite a
lot, and by doing a partial low level format he'd destroyed more than
he thought, and the physical damage to the disk that he'd done by
switching off while the disk was in the middle of accessing the most
sensitive areas of the disk (the FAT and directory) was pretty
crucial.  I explained that my quote was for recovering the original
database, and that I was assuming that he'd backed up everything else
before embarking on his orgy of destruction.

Well, you can probably guess by now, that he'd omitted to take that
obvious, common sense precaution.  Not only had he not backed up a
crucial database and lost it by that omission, he'd not learned from
that mistake, and hadn't backed up what was left on the disk before
pounding in into the ground with everything he could find.  And
furthermore, since it wasn't his computer, he didn't even have the
originals of the software that was on the disk.

I told him that all I was going to be getting for him, was that
database.  There was little point in my reconstructing the executable
files, since they were on diskette somewhere, and it would cost him
extra for me to do it.  I told him that he didn't stand a hope in hell
of being able to cover up what he'd done, and that he'd have to own up
to his client at least to some extent.  He said he'd think about it.

When he called me back, I half expected that he'd used a tin opener on
the disk, in a desperate but misguided attempt attempt to get at the
contents, or possibly a hacksaw, or maybe he'd be really ingenious.
But he hadn't been able to come up with any more good ideas, and he
was just phoning to say that he'd send the disk round.

I won't bore you with the tedious details of how I rebuilt that
database.  I had to undo what Simon had done, piece by piece, before I
could even attempt the original problem.  I had to get the disk
working again, convince Dos that it existed, fool Dos into thinking
that it was a valid Dos device, and then go looking for the data.  All
the data was there on the disk, but I had to find each cluster, and
make a note of where on the disk it was, and decide how it fitted in
with the others.  It was a bit like doing a jigsaw puzzle, except that
the picture is a bit repetitive, and you don't know what it is
supposed to look like.  For example, most people think that DOS stores
files in cluster order.  Actually, the chain of clusters can loop back
on itself, so that even if you know that a file consists of clusters
1034, 3422 and 8714, they might not be in that order.  The file might
start at 3422, go on to 8714, then finish at 1034, or any of the six
possibilities.  It was made worse by the fact that there were multiple
copies of the same data on the disk, and there was no obvious way to
know whether I was looking at a cluster from the main file, or one of
the copies.  Inevitably, I wound up with a file that had duplicate
records.  To deal with that, I sorted the database using the Turbo
Toolbox sort routines (they are very fast) and then wrote a program to
go through the database to weed out duplicate records.

When I'd finished, I invited Simon round to see the outcome.  I wanted
him to see exactly what he was getting for the rather large sum of
money that I was charging him, so that he could decide for himself
whether it was worth paying for or not.  I do this when a data
recovery is incomplete - the client always has the option of paying
nothing, and having his disk back, exactly as it was when he brought
it.  I never write anything onto a client's disk, I always work on one
of my own, on the grounds that there is usually something wrong with
his disk, and I don't want it crashing in the middle of my working on

Simon looked through the database, checked the number of records, and
looked rather relieved.  While he was in this mood, I relieved him of
an embarrassingly large cheque, which he had no trouble at all in
writing.  After I'd given him coffee, and we were chatting, I asked
him what would have happened if I hadn't got that data.  He explained
that his customer would have probably gone out of business, and that
he would have sued Simon for a five figure sum - possibly even six.

I think I undercharged.