Let's develop an open-source media archive standard

I did not say it was the primary purpose. The data blocks work hand in hand with the formatting information. It is fine to make a standard extensible, but what good does it do if the (I hate the use the word) file can't be gotten without jumping through major hoops because how the data was stored in the image file wasn't extended out to make blocks. If you have to iterate through formatting information to get data then you have to be intimately familiar with the disk format in use. It means any GENERAL utility to read an image file for data access will have to KNOW about all machione supported rather than just getting some type of data identifier and reading the data out. I think part of the problem here is that the word file is being taken literally to mean filename, size, data, etc. I am using in the context of a block of data. It has NOTHING to do with how the data is on the disk, where it is stored, the recording format, etc. It is just a piece of data... Sellam in a later email thought that I was proposing that the data be duplicated twice - one for file access and one for format data - NO, that is not what I was talking about. The formatting information contains no data other that what may be necessary for things outside of what is considered a sector on a drive such as address mark, etc(note: this does not preclude sequential data - I am only using this as a specific example in this email). I am talking about two separate sections inside the same image file. One of the sections contains data blocks. The other has specific formatting information and POINTS to the data in the data blocks. A utility program could then SIMPLY get any type of data out of the image file without the utility being out of date as soon as someone added a new physical format. I have tried to make this email as clear as possible, so there is no misunderstanding of what I have proposed. best regards, Steve Thatcher -----Original Message----- From: "Dwight K. Elvey" <dwight.elvey(a)amd.com> Sent: Aug 11, 2004 8:11 PM To: cctalk(a)classiccmp.org Subject: RE: Let's develop an open-source media archive standard ---snip--- Hi I'm not saying to make it impossible to do, just that it shouldn't be considered as a primary purpose. Using an extendable language like I've suggested, one can add such features. Part of the problem is that when someone creates the archive, they may not even know the file structure of the disk. I would expect the specification to be broad enough to allow such. Still, the primary thing is to be able to recreate the original material. To me this means that any input to some emulator may mean that it requires some post processing. How would one know what some some format a particular emulator wanted? How would a person always know how to read the directory structure and be able to extract files? If one wanted to work in all cases, I'd expect that the person writing the emulator would provide the needed post processing to extract such information. Otherwise, they'd only be able to read archives of disk that were specifically created for their system. Those archives that the person didn't know the file structure would be useless unless. Such things are secondary functions. They shouldn't be restricted be to capture the entire information in as close to the original format as possible. Creating post processors could easily be done as a separate outside function for special purposes. Dwight