OT: paging MAC expert(s) --- What's a Performa? - test-drb@ccmp.vtda.org

20 Nov 2001

This was misrouted and returned to me, I know not why or where ... Let's try
again ...
Dick
...
  -----Original Message-----
 From: Richard Erlacher [mailto:edick@idcomm.com]
 Sent: 20 November 2001 01:08
 To: classiccmp(a)classiccmp.org
 Subject: Re: OT: paging MAC expert(s) --- What's a Performa?
 If you're meaning operating on the tape contents, you're talking about weeks
 to
 months.  The bits of a file are scattered around the disk, since it's random
 access, albeit in "clusters" or whatever you choose to call them, and in
 blocks,
 as the data buffer stores them, but unless you KNOW where the directory is
 in
 the bitwise image of the disk, and unless you know where all the pieces of
 the
 drive are to be found in the tape image, I'd submit it would be a mite
 tedious.
 The problem, of course, with image backup, is that the bits have to be
 extracted
 from the drive at the raw data level, i.e. with controller commands you
 normally
 don't deal with, and they can't be faithfully restored to a drive that's not
 physically identical to the one you started with, i.e. same number of heads,
 cylinders, sectors, etc, PHYSICALLY, else things fall apart, since we don't
 know
 how the drive firmware deals with translating from the block-level commands
 the
 OS may choose to send it, though it doesn't have to, to the buffers-full of
 data
 that the drive coughs up.
 Remember, when you restart the system, it has no OS other than what you can
 load
 from a floppy.  IF that's the same, which certainly isn't the case under
 WIndows, as what you used to do the backup, then you're able, potentially,
 to
 deal with the data to be transferred to the newly cleaned drive in the same
 way
 that this particular OS deals with it.  Of course, the OS doesn't know what
 you're doing, and doesn't know how to read the data on the disk, except as
 raw
 data, dealt with in buffer-fulls, and than only using the code you've
 written.
 Dick
 ----- Original Message -----
 From: "Christopher Smith" &lt;csmith(a)amdocs.com&gt;
 To: &lt;classiccmp(a)classiccmp.org&gt;
 Sent: Monday, November 19, 2001 4:00 PM
 Subject: RE: OT: paging MAC expert(s) --- What's a Performa?
 
-----Original Message-----
 From: Richard Erlacher [mailto:edick@idcomm.com] 
  If your recorded "backup" is a
bit-for-bit image of the disk contents,
 transferred to and from tape, there's no interpretation of
 the contents into
 files that can take place, is there? 
 That's an interesting way to phrase this particular question, since the
 contents are already in the form of "files" -- that is, if you ask the set
 of drivers that got them to the disk in the first place. :)
 I believe it's possible (though it would be slow) to interpret a  bit-for-bit
  image directly on a tape and extract any given
file, along with  attributes,
  etc.  In fact, any operation that would be
possible on a disk, in this  case,
  could be handled on a tape.  The clincher is that
it would involve a lot  of
  seek/rewind/seek/etc/etc..
 The underlying O/S need not even know the difference between the disk and
 tape, except to know that the tape is removable (...that's not absolutely
 required), and perhaps that it's incredibly slow.
 The worst that would be required is a device abstraction layer or the  like.
  You could write one yourself which would make the
tape device "look" like  a
  disk device, for systems which don't have
such a thing, and that would be
 enough.
 How would you like to be able to mount your backup tape, and use a
 file-manager on it? ;)
  The Microsoft Backup that came with DOS, (a)
never really was
 a backup, but,
 rather, was just a copy, and (b) never worked together with
 its "restore"
 function.  Under DOS, copies were adequate, since the context
 didn't matter. 
 If you mean that it didn't store attributes, or that sort of thing, you  may
  be right (never paid attention.)  On the other
hand, you're also right to
 say that it wouldn't particularly matter under MS-DOS.
 Regards,
 Chris
 Christopher Smith, Perl Developer
 Amdocs - Champaign, IL
 /usr/bin/perl -e '
 print((~"\x95\xc4\xe3"^"Just Another Perl
Hacker.")."\x08!\n");
 '