Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!gem.mps.ohio-state.edu!apple!well!shf
From: shf@well.UUCP (Stuart H. Ferguson)
Newsgroups: comp.sys.amiga
Subject: IFF CAT archiver (was: Voice Mail on Amiga)
Message-ID: <14134@well.UUCP>
Date: 17 Oct 89 08:10:43 GMT
References: <688@orange6.qtp.ufl.edu> <KIM.89Oct2022514@watsup.waterloo.edu> <125829@sun.Eng.Sun.COM> <4283@sugar.hackercorp.com> <14085@well.UUCP> <4361@sugar.hackercorp.com>
Reply-To: shf@well.UUCP (Stuart H. Ferguson)
Distribution: na
Organization: The Blue Planet
Lines: 62

+-- karl@sugar.hackercorp.com (Karl Lehenbauer) writes:
| In article <14085@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes,
| regarding my IFF CAT archiver:
| >Has the problem with this been fixed?  I remember noticing that the 
| >early one created incorrect IFF files.
| 
| What Stuart is referring to is that the CAT archiver embeds a chunk containing
| the archive entry name (i.e. filename) within the FORMs that you save, rather
| than external to it.

Ah, yes.  I remember the problem now.

| Stuart contacted me when the first version of the CAT archiver came out,
| saying
| that it was illegal to embed chunks within FORMs that your program doesn't 
| understand.  After careful reading of the spec, I believe that it *is* legal 
| to embed chunks within FORMs you don't understand, 

Yes, it is legal, it just isn't very friendly.  But as long as people know
that if their FORM's contain IFAR chunks, they may be damaged.  (Of course,
how are people supposed to know that ... ?)

The real problem (and I looked at the new version and it still does this)
is that the IFAR (filename) chunk is stored just inside the first level
of whatever IFF structure you give it.  Now this is fine for files which
are FORM's, since the IFAR chunk then just becomes another data chunk in
the file which is (you hope) simply meaningless in that context.  The
problem comes in when you try to archive an IFF file which is a LIST or
a CAT, such as one of these iffar archives.  In this case, the IFAR "data"
chunk is inserted inside the LIST or CAT, but not inside a FORM, which is
*NOT* a legal IFF file.  The iffparse.library test program "sift," which
just scans files for IFF-ness reports error -7: IFF syntax error.  EA's
"IFFCheck" crashes (!) (I guess you could call that a type of error
message :-).

To summarize, if you try to concatenate two archives with iffar, or archive
any other CAT's or LIST's, the resulting file will not conform to the
IFF standard.

| Anyway, I had need of it.  I didn't have time to do a massive rewrite.  So I
| fixed a bug that could cause some entry names to be shortened and renamed the
| name chunk to IFAR.

Understood.  Since this is the first program I've seen that actually does
something interesting with generic IFF files, I don't want to knock it
down too badly.  I must stress again, however, that anyone using this
program must not assume that the files they are producing are good IFF
files.  Mostly they are, but they also may not conform to spec and 
may gag or crash correct readers.

The thing I want to avoid is getting a proliferation of these slightly
out of spec files around and then having all this pressure to "bend" the
standard to adjust for them.

	- Stuart

"we're looking at the big sky
 you never understood me,
 you never even tried."
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC		(ferguson@metaphor.com)