20 Nov
2001
20 Nov
'01
6:28 a.m.
-----Original Message-----
From: Richard Erlacher [mailto:edick@idcomm.com]
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
Well, I haven't got much faith in them to begin with. They could work for
1000 years on a 20 minute job and still mess it up. I'm not saying that it
might not actually take that long, just that m$ aren't competent enough to
be a good indicator.
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,
I was assuming you'd know the filesystem type at the time of the backup. I
don't suppose it would be absolutely necessary. You might also recognize a
filesystem by magic number/signature, or the like.
[snip]
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
Well, "otherwise identical" is dangerous territory at any rate. :) You're
right, though, in that depending on the way the software components interact
with the drive, one or more of these things might really screw things up. I
suppose that would require one to know the internals of each system with
which you plan to use this method.
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
... which may be ok, depending on how the system interacts with the device
in question. Of course, if you find that the system depends on the data
being in some physical location, rather than in a logical location, you'd
have to correct for that or _just not do it_ ;)
[snip]
sent, you may be disappointed with the results because
IDE
drives hide too many
details from the end-user.
Yep. Tell me about it.
[snip]
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.
That depends. For instance (This will now get very hypothetical), if the
O/S handles data in logical blocks, and doesn't care too much the actual
geometry of the drive, you might be ok with not knowing about the device.
That is, with the exception of bad blocks. (Really I guess I'm talking
about faking a standard interface even when it doesn't exist here)
[snip]
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.
On the other hand, as some friends of mine are wont to say: "Neither S in
SCSI means standard."
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.
Can't argue with that.
Chris
Christopher Smith, Perl Developer
Amdocs - Champaign, IL
/usr/bin/perl -e '
print((~"\x95\xc4\xe3"^"Just Another Perl
Hacker.")."\x08!\n");
'