Disk archival techniques

[Brian Wheeler]

On Wed, 2005-05-18 at 14:00 +0000, Jules Richardson wrote:
> On Wed, 2005-05-18 at 08:13 -0500, Brian Wheeler wrote:
> > I guess what I was getting at is there should be a library of standard
> > types which fully define the format.  1541's look the same 99% of the
> > time unless half-tracks, fat tracks, or another copy protection scheme
> > was used.  So if there's a library that fully defines what a 1541 _is_,
> > there's no reason to have that exact definition copied for each disk
> > archived.  Not that it really takes up that much space, but it does make
> > it more tedious -- do you want to enter the track/sector geometry for
> > every disk you copy?
> 
> Ahh, OK - not a problem at image creation time, *providing* that the
> image format includes all the data needed to recreate that disk
> *without* the repository. In 30 years time, there's no guarantee that
> the repository will be in the same format, or easy to get hold of etc.
> so there's a danger that an image will be junk if all it has in it is a
> label saying that the source disk was in "Fred's own disk layout"
> format. 
> 

Good point.  Yeah, the formatting information should probably be
included with every image, but a disk format repository solves alot of
the tedium.


> But yep, a repository could make the UI of any creation tools cleaner -
> but it's a seperate project from the image format itself I think...
> 

Yes.

> Personally I think it's achievable, providing we stick to worrying about
> floppies at the moment. Tapes, hard drives, ROM images etc. can come
> later - doubtless they'd share some field names, but the structure is
> sufficiently* different that it's too much to take on in a first cut.
> 

Tapes are an issue since they're really not a stream of bytes -- there
are tape marks and gaps.  The simh virtual tape format seems to be
fairly complete in that respect:

http://simh.trailing-edge.com/docs/simh_magtape.pdf


Brian

> *OK, gut feeling it that it's not *that* different and floppy images are
> actually the most complex of the lot. But as someone else has said, it's
> too easy to get bogged down when trying to come up with a "do
> everything" solution. I can't see that it matters if there ends up being
> seperate futurekeep formats for different classes of media.
> 

> cheers
> 
> Jules
>