20 Dec
2014
20 Dec
'14
2:51 p.m.
On 12/20/2014 01:33 PM, Fred Cisin wrote:
There is always an off chance that some of the
software that uses those
files may expect a fixed length, and will freak out if the length isn't
what it had expected.
The SIMH format provides for an EOM record, so things are pretty safe in
the respect of trying to read past EOM (end of media). That's the great
thing about tape--you have so many feet of tape (imprecisely specified)
and that's it. You can't write on air, nor read it.
Therefore, there is some risk involved in appending
anything
to the file(s).
So not much of a difficulty with that.
Could you create a separate file that is associated
with each file?
filename.DAT and filename.INF
That way, the .DAT file can be an "UNCORRUPTED" exact image of the
original data.
filename.INF could be a simple text description, maybe even in complete
sentences, containing whatever is known about the file, such as record
structure(s), etc. (and editable if/when more is learned!)
If there is an expectation of an extreme quantity of data files,
then the .INF file should have a fixed machine parseable format,
followed by a freeform text component at its end.
Of course, there's an issue there. What's a file? If there's only one
lump of information, you know. But if there are several, then you get
into the issue of file names, record formats, etc.
For example, how do you represent a Mac resource fork on DOS?
What I'm trying to do is to think not only 40+ years back, but 40+ years
ahead. I know that that's a tall order, but you can't blame one for
trying...
Personally, I've found it surprising with what knowledge gets lost in 20
years...
--Chuck