Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!psuvax1!rutgers!texbell!sugar!karl From: karl@sugar.hackercorp.com (Karl Lehenbauer) Newsgroups: comp.sys.amiga Subject: Re: Voice Mail on Amiga Message-ID: <4361@sugar.hackercorp.com> Date: 15 Oct 89 16:31:20 GMT References: <688@orange6.qtp.ufl.edu> <125829@sun.Eng.Sun.COM> <4283@sugar.hackercorp.com> <14085@well.UUCP> Reply-To: karl@sugar.hackercorp.com (Karl Lehenbauer) Distribution: na Organization: Sugar Land Unix - Houston Lines: 49 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. 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, however, the original choice of the entry name chunk ID (FNAM) was very poor and, further, I agree with Stuart that the archiver should not have done this because it would be better in many ways (including reducing overhead) to have this information outside of the FORM being archived, but of course in some IFF-compatible manner. Peter and Stuart both wanted it to use LISTs, as I recall, because they didn't like my plan of just having FORM IFAR chunks before the real chunks, i.e. the adjacent position of IFAR FORM and user's archive FORM chunks associated user's name (and eventually other info chunks) to user's FORM. Of course, I would probably have to write it and the LIST way is a lot harder, plus the advantage of the archive not having to get too heavy into cracking FORMs (as it sort of does now) is somewhat reduced, because they're wanting a more complicated structure. One thing about the archiver, if you retrieve a FORM back into a file, it is supposed to remove the archive name chunk from the FORM. So it shouldn't impact programs that only know FORMs. (Stuart reported trouble when a FORM already contained an FNAM chunk.) 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. Since there aren't any commercial CAT readers that I know of, you guys will be writing or adapting your own ILBM, 8SVX, etc FORM-reading code to read from the CAT (it's pretty easy, if you have or adopt a read routine that can start reading a file that's already open and leave the file pointer at the start of the next chunk, it can read files and FORMs -- and take anything else you need from the archiver source (it's public domain)), so your code shouldn't freak out when it sees an IFAR chunk, since you can make sure it won't. -- -- 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