Path: utzoo!attcan!telly!ziebmef!mcp
From: mcp@ziebmef.uucp (Marc Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: fib_DiskKey semantics
Message-ID: <1989May12.183725.25380@ziebmef.uucp>
Date: 12 May 89 22:37:24 GMT
Reply-To: mcp@ziebmef.UUCP (Marc Plumb)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 62

I'm actually writing the file system I was blathering about so much
some months ago, and am having still more problems with that nemesis
of all Amiga FS writers, ExNext.  I would cheerfully strangle the
dimwit who defined half of its semantics so badly, and didn't define
the other half at all.  But I think I've already posted that flame.
Suffice it to say that modifying a directory while it's being ExNext()ed
can cause files to be skipped, reported twice, or even reported
despite the fact that they reside in a different directory.  FFS fixes
some of those bugs, and they're all pretty rare, but it's still
tremendously brain-damaged.

Anyway, in TransAmi 2,2, John Toebes and Doug Walker mention that some
programs (death by slow torture) trash everything in a FIB except
the DiskKey and the first 30 characters of the name between ExNext
calls.  In my FS, I'm guaranteeing that when used properly (same lock
used for all ExNext calls, full FIB passed), ExNext() will have no bugs,
but as a concession to existing software, I'm trying to make it no more
buggy than the old FS when abused.  So if I could make good use of the
fib_DiskKey (since a file can be renamed at any time, the name is
pretty useless), it would be a bonus.

However, I've also heard that some people (Ameristar?) use the DiskKey
as a unique file id.  So I'm not quite sure what is and is not allowed
with it.

Since its interpretation is not documented, then strictly speaking, I
could return 32 arbitrary bits from any Examine() or ExNext() call.
But in the interests of not breaking everything at once, I'm willing
to include a few kludges.  My questions are:

Is it required that Examine()ing the same file will always return the
same DiskKey?  Is it required that Examine()ing different files will
always return different DiskKeys?  Note that these two are orthogonal -
I could guarnatee that no two Examine()s will ever return the same
DiskKey and satisfy the second but not the first.

Is it required that ExNext() calls obey the same rules?  Only with other
ExNext() calls, or must similarity and uniqueness guarantees span Examine()
and ExNext()?

Any other information about the semantics of ExNext() or the various fields
of the FileInfoBlock (what does a fib_EntryType of 0 mean?) is also greatly
appreciated.  Thanks!
--
	-Colin Plumb

P.S. Does anyone have any ideas about directory formats?  I'm hovering in
the vicinity of 24 bytes for an empty file with a single-character name and
no comment, so I can promise cheap files, but whether to use an Amiga-style
directory that's a lot of pointers to file headers or a CP/M-style
directory that's basically an array of file headers proper is still an
open question.  Then there's the Mac HFS scheme... does anyone know any
other directory schemes?  Note that at the level I'm working, there is
no way to ask for a file's name without size, date, flags, and comment, so
splitting them up "to get all those big comments out of the way since dir
never uses them anyway" is not useful.  You could argue for splitting
up the information reported in a fib from the pointers to the file's disk
space, but this means that growing a file would require you to update both
places - one to record the location of the new data, and the other to record
the new size.

Thanks a lot for any ideas!