Date : Fri, 01 Mar 1996 14:30:22 +0100
From : Robert Schmidt <robert@...>
Subject: Re: Emulation systems
>However file-system control data doesn't really belong within the data
>file itself.
I don't see the host file as "the data itself". By keeping the file control
data *with* the data itself in a "BBC file" entity, you encapsulate all you
know about a file in one place. Working with an index file feels artificial
when the host filing system is really sufficient.
>A simple copy program that understands the index file would be needed
>anyway, really.
It wouldn't be needed if file control data reside in a header in the host
file. You need to make sure that no two host file names identically named
before copying, though - by renaming one of the conflicting files to
anything.
What "scares" me about index files is that one accidentally copies one
indexed directory into another, destroying the index file in the target
directory forever. With Linux, this file can be rebuilt automatically -
this is not possible for BBC files, as load/exec addresses would be lost,
for example. I guess this could be helped by using an index file
*extension* instead of a full name (like __CATALOG__). Wouter Scholten's
bsplit program produces a *.CAT file, for example. There will still be
potiential conflicts with index numbers (if these are used), or with
conflicting host file names in general.
>> If you want to move just a few
>> files, you have to edit the index file manually, and make sure you
keep the
>> correct entries with the files you move.
>
>Another way is to just copy the file into that directory, and have a
>synchronization utility, and/or arrange for the emulator to silently
>update the index file of it detects any changes to the directory.
Well, where should the emulator get info about the new files, unless the
info is in the host files themselves?
>With the index file, this information is already there (although you
>should probably to a quick scan to sanity check the file).
With the index file, more things could go wrong, basically. A scan of the
index file + verifying the existence of files is not much cheaper than
scanning the headers of all BBC files in as directory. With headers, the
information is also "already there", as I see it.
>Future proofing. Mirroring the version number of the archive *writer*
>allows the reader to do cunning things in the face of developement and
>cock-ups^H^H^H^H^H^H^H^H format-revisions.
Yep, I agree. A version number is a Good Thing.
>Oops - so it does. It means a completely different thing to the CFS
>locked flag though, doesn't it (read-only as opposed to execute-only).
>Doesn't ADFS have a load of different flag settings aswell?
Does anyone have information on what flags ADFS supprts for each file? HDFS
supports Read, Write, eXecute and Lock.
>We need to decide whether to:
>i) ditch the flags completely - they cause too many problems and aren't
>*really* necessary.
>ii) choose a sensible number to use. (DFS semantics *only*, CFS/DFS?)
>iii) implement all available flags and make only appropriate ones visible
>at any time.
We could select the most common/general ones - I suggest "Readable",
"Writable", "Executable" and "Locked" (un*LOADable or undeletable). These
should be enough to support most semantics.
>Nightmare. To get them to work the emulator has to have some pretense of
>operating under CFS - either by emulating the tape hardware, or by
>emulator hooks to catch OSFILE stuff, for example.
I don't know the implications of supporting CH."" - is this hard? Given the
BBC file name of the "next" file - either from the header or from the index
file entry of the last file read, figuring which file to read is easy. I
guess the problem is hooking the OS, then?
robert
--
Robert Schmidt - robert@... - http://www.idt.unit.no/~robert
Maintainer of "The BBC lives!" page:
http://www.idt.unit.no/~robert/bbc/bbc.html