Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!hagbard!luth!d88-mbe From: d88-mbe@sm.luth.se (Michael Bergman) Newsgroups: comp.sys.amiga Subject: Re: Compressed archive format Keywords: chinese menu Message-ID: <1056@tau.sm.luth.se> Date: 28 Aug 90 23:44:23 GMT References: <1990Aug25.180851.4401@zorch.SF-Bay.ORG> <1051@tau.sm.luth.se> <1990Aug28.180026.20641@zorch.SF-Bay.ORG> Organization: University of Lulea, Sweden Lines: 139 xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: [about LHwarp] >Well, that makes it pretty useless for working in the larger context >of building archives/swapping stuff across non-Amiga hosts, and I >hope folks will stop submitting archives in that format, then. I agree. LHwarp has it's uses, but *not* for building archives on non- Amiga hosts. It is convenient when you want to pack the entire AmigaDOS file structure on a disk 'as is' and put it on other media, though. > Lharc >I put a couple of hours into trying to port it to my current system, and >decided I was growing old a lot faster than the code was growing smart, >and trashed my work-in-progress. I know, I know. I wish it was available for a wider range of systems. On the other hand I made a lot of people *very* happy when I posted a note here in c.s.a saying that a UNIX lharc compatible with Amiga versions existed! I guess we have to begin somewhere... >Also, at least the Amiga version is buggy, in that it promises not to >store duplicates of the same pathname, but in fact does do so. Hmm, I *think* this is fixed in the new v1.20. Check it out. 1.20 is also a lot faster (35% unpacking & 15% packing) than 1.10. >I have the impression Zip is a proprietary format, and also not widely >ported to mainframes; is either of those right? If so, that argues >against their use. Yes, yes. I agree again. Sure, PkaZip is nice and has a very high "overall" performance, but... the tool we want to use *has* to be available for mainfraime systems. Can someone port it? (Just kidding.) >Well, I'll give up a _lot_ of time efficiency (like three or four to one) >for 5% better packing, since, as you note, I can background and ignore the >packing time, but I have to pay for the storage space in cold, hard cash, >and I pay for it in perpetuity. Once again we share the same opinion. Strangely enough, not all people do. >Well, you at least are following the conversation, so if no one beats >you to reposting them, and you find the time free, I for one would >appreciate the effort on your part. Ok. I'll dig them up and type them in tomorrow (oops, it's 1:15 AM already, read today :-). BUT these might be the same figures that appeared in Amiga World! I can't check, I'm afraid. >A tool that works across a wide range of platforms, and is available in >source code form is a necessity if the current multiplicity of archivers >is to be replaced by a single tool. Well, the reason for the increased use of LHarc in spite of it's flaws (e.g. not being available for most systems) is the efficiency. It appears to me that people are willing to give up a lot for better packing. I think that LHarc will win in the end and that new versions for other systems will be written. As I said before, the archive tool has to meet a demand from the users, other- whise noone will use it. It *seems* as if the packing efficiency is the most important aspect here. It is also possible to make the archiver programs pack and unpack faster. The fastest versions for Amiga are much faster than the UN*X version 1.00. >Maybe I'll find time to rip the Huffman code out of lharc and replace it >with the more efficient arithmetic encoding, for another 5% gain Hmm.. If you ever do, send it to me so I can try it, will you? I'm not sure it's a good thing to break another "standard" by using this arithmetic encoding for just another 5%, though. Then we would have yet another archiver and versions for different computer would have to be written before people could use it. Unless of course you would take it upon yourself to write Amiga/IBM PC/Mac/Xenix/VMS/UNIX versions all at once..:-) Lharc isn't nearly as flawless as zoo yet and the UNIX version lacks *lots* of options that a good archiver must have, but it's a beginning. (There were more that one version of zoo too, right? :-) >Thanks for your comments and for the script, Michael. About the script - I gave you an old version, sorry! This is the latest. Mike #! /bin/sh # # Reconstructs zoo archive(s) to lharc archive(s) # using /tmp/ for temporary storage. # Before use, check that the zoo archive(s) aren't damaged: zoo Lm * # # M. Bergman Last changed 1990-06-06 # if [ $# -lt 1 ] then echo "Usage: zoo2lzh " echo " You must have rw permission both to the zoo archive(s)" echo " *and* the catalog(s) they are in." echo " .lzh file(s) will have the default permissons." echo " The .zoo extension can be omitted." echo "" exit 1 fi TMPDIR=/tmp/.z2l#$$ mkdir $TMPDIR chmod 700 $TMPDIR for ARG do if [ `echo $ARG | awk -F. '{print $NF}'` = zoo ] then EXT=`echo $ARG | awk -F. '{ORS="."} {for (i=1; i < NF-1; i++) print $i} {ORS=""} {print $(NF-1)}'` fi if [ -w $EXT.zoo -a -r $EXT.zoo ] then WD=`pwd` ARCHFILE=$EXT if [ `echo $EXT | awk '{print substr($1,0,1)}'` != / ] then ARCHFILE=$WD/$EXT fi echo "" echo "Reconstructing $ARCHFILE.zoo" cd $TMPDIR zoo e// $ARCHFILE.zoo rm $ARCHFILE.zoo FILES=`ls -A` echo $FILES lharc a $ARCHFILE.lzh $FILES rm -fr $FILES cd $WD else echo ""; echo "zoo2lzh: $EXT.zoo nonexistent or limited permission" fi done rmdir $TMPDIR echo "" -- Michael Bergman Internet: d88-mbe@sm.luth.se // Undergrad. Comp. Eng. BITNET: d88-mbe%sm.luth.se@kth.se \X/ U of Lulea, SWEDEN ARPA: d88-mbe%sm.luth.se@ucbvax.berkeley.edu UUCP: {uunet,mcvax}!sunic.se!sm.luth.se!d88-mbe