shf@well.UUCP (Stuart H. Ferguson) (10/17/89)
+-- 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)
karl@sugar.hackercorp.com (Karl Lehenbauer) (10/18/89)
In article <14134@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >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. You are absolutely correct. 'iffar' should be considered broken with respect to creating CAT archives containing CATs and LISTs. >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. Good point. Your remarks have increased my desire to create a new version that is more compliant. Archivers are tough to get "right," though, and they have to work pretty perfectly in terms of not losing anything or people end up wanting to kill you, so I still don't know when I'll be able to do it. >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. Thanks. -- -- uunet!sugar!karl "There is hopeful symbolism in the fact that -- flags do not wave in a vacuum." -- Arthur C. Clarke -- Usenet access: (713) 438-5018