19 Nov
2001
19 Nov
'01
9 a.m.
-----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");
'
19 Nov
19 Nov
11:07 a.m.
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" <csmith(a)amdocs.com>
To: <classiccmp(a)classiccmp.org>
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");
'
8438
days inactive
8438
days old
1 comments
2 participants
participants (2)
-
csmith＠amdocs.com -
edick＠idcomm.com