Disk archival techniques

On Tue, 2005-05-17 at 15:07 -0500, Randy McLaughlin wrote: Yep, me too. From when we were bashing around ideas about this though a few months back it seems that's a minority viewpoint; most people want data embedded in the metadata. For hard drive images I zero-pad any bad data but also include metadata in a seperate file - including disk geometry, which blocks are bad, resulting dump checksum, timestamp etc. along with anything else that might be particularly useful. For floppy images things would be significantly more complex though (due to factors as mentioned - variant sectors/track, different encoding for different tracks etc.) The idea behind futurekeep though was to make the metadata highly structured and in a similar vein to HTML in that clients could handle as much of the data as needed (eg. someone not dealing with variable bit rate images wouldn't need a decoder that could handle them). Ideally it'd be human-readable too (after a fashion) - e.g. XML - so that the data could be reconstructed into a disk image "by hand" even if some whizzy util to do it wasn't present. (understanding it at a file level is obviously outside the scope) That doesn't seem *too* much to ask; basic metadata can be created for existing images without a lot of hassle *if desired*. To me such a format's more useful for future image creation though, particularly in the case of less-common systems; the popular machines are likely to be covered by their own archive formats already and the following large enough that lack of data is not (yet) a problem. Rather than messing around with proprietary image formats for those, or formats that aren't particularly descriptive, it'd be nice to start from day 1 using something that allows us to capture all the useful stuff that goes along with the raw data. cheers Jules