It's the "quite a bit of extra work" that concerns me, as the boys at M$
haven't
managed to do it right yet, and they've been at it to the tune of 100K man hours
per year for a decade or so. Recording a bitwise image of what you receive from
the disk may or may not give you all the information you need to recreate the
files, since you may or may not know how the OS deals with them. What's more,
in order to make a complete record of the drive, you have to record every bit it
has on it and save them as a single unit, since you don't know what the drive
does with the data you send it. That's the same reason, BTW, why the drive to
which you write such an image must be an EXACT duplicate of the one from which
the image was recorded. The second drive may otherwise claim to be identical
but have a different number of sectors per physical track, use different mapping
arrangements, etc, and, especially, have different bad blocks. Since you're
going to send data that goes to where the drive sends it and not necessarily to
the same physical location from which you got it because the drive may use
different modulation, servo coding, etc, and therefore may have a different
number of sectors per track in the region of the drive to which the data is
sent, you may be disappointed with the results because IDE drives hide too many
details from the end-user.
Depending on the level of the interface you use, you may not be able to use
image recording at all. Further, if you don't know absolutely for certain, what
the drive does with the data you send it, and what the OS does to process data
to and from the drive, you're on thin ice.
I'd not recommend using image recording with a later generation IDE drive at
all. Since SCSI is well established as to how it operates its data management,
it yields more hope that you can process an image, though the vagaries of the OS
are still a limiting factor.
Image recording should work fine with MFM- and RLL-encoded drives, even on a
track-by-track basis, and those offer some hope that one could substitute one
sort of drive for another but hte ones which use BOTH CHS and LBA addressing
won't tolerate the sort of operations to which an incrementally developed OS
like Windows could create.
Dick
----- Original Message -----
From: "Christopher Smith" <csmith(a)amdocs.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, November 20, 2001 10:07 AM
Subject: RE: OT: paging MAC expert(s) --- What's a Performa?
-----Original
Message-----
From: Richard Erlacher [mailto:edick@idcomm.com]
medium, and subsequently writing them back to a
physically
identical (not just
logically identical) target, without consideration for
Why not just logically identical, then? ... assuming, of course, the same
o/s would handle devices which are logically identical in an identical
manner. (This may not be a safe assumption)
[snip]
The bitwise image transfer from disk=>tape can
be done
without knowledge of
either the compression scheme or of the OS/file system used
on it. It does
require, however, that the entire image be recorded so it can
be restored in its
entirety. The result is that you can use a different OS to
do that task though
it's not required, and the penalty is that you have no access
to the file data,
though you could, I guess, go to the trouble of deciphering
the bitwise image
into a logical file system if one originally existed. You
can do that under any
circumstances, but it's a lot of trouble and requires you
know a great deal
about the low-level processes of converting the data on the
orginal drive into
the files comprising it.
I think you've just summed up my previous point. That being, of course,
that if you can record a bit-by-bit image, you should also be able to
interpret this image (with quite a bit of extra work), and find the
component files. In fact, I'd add that depending on the amount of extra
work you're willing to do, you can likely restore the image in a "logical"
fashion to a volume that is completely different from the one on which it
originally resided.
Regards,
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl
Hacker.")."\x08!\n");
'