Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!convex!rosenkra From: rosenkra@convex.com (William Rosencranz) Newsgroups: comp.sys.atari.st Subject: Re: Major Problems Unpacking 'lzh' Files Message-ID: <1991Jan08.061722.26635@convex.com> Date: 8 Jan 91 06:17:22 GMT References: <10472@lanl.gov> Sender: usenet@convex.com (news access account) Organization: Convex Computer Corporation; Richardson, TX Lines: 79 Nntp-Posting-Host: convex1.convex.com In article <10472@lanl.gov> wrs@infidel.lanl.gov (William R. Somsky) writes: >I've recently gotten back into using my ST, and have been trying >to download various files from atari.archive.umich.edu, but I'm >having MAJOR difficulties unpacking 'lzh' files. this is one of my pet peeves, so skip this note if u don't want to hear my ranting... lharc has somehow become the defacto standard archiver for c.[bs].atari.st and archives (like terminator) because it does a significantly better job at compression than arc (at least arc 5.21 and earlier). fine. only problem is that there are at least 3 different versions that i am aware of and early lharc versions were very buggy at best (IMHO). in contrast, the excellent zoo package has never been a problem on any system i have used, from pc to cray (though the cray port was non-trivial :-). and it is the standard archiver for c.b.ibm.pc (which generates much more traffic than the st groups). lharc is very flakey, though i have not gotten an newer unix version, so it may have improved in the last 6 months so don't get on my case about that. lharc is 1) slower than zoo (MY tim is valuable, i hope you think yours is, too), 2) marginally better at packing (still not as good as compress, of which there is a robust st version, and cost of floppy disk is minimal), and 3) is not centrally maintained, as far as i can tell. it is also not very common outside the usenet st community, from what i can see. i can understand the maintainers of terminator for wanting to minimize the disk space which they thoughtfully provide as a service for us, but i really don't think the savings over zoo is (in total) much more than 5 to 10 percent, if that. i just don't think that the savings gained from lharc is worth the hassles (i.e. manhours lost) to justify its use, though i suppose it is futile at this point to try and re-standardize on zoo (a better choice overall, IMHO). and i do not know of any *significant* features which lharc has that zoo does not have. i have to admit, though, that i have had few problems with lharc for the past 6 months or so, so that the situation has improved since lharc's initial appearance (which was a mess at best). i think it originated in japan, though that is obviously not the reason for its problems (there were too many people scrambling to get the ball rolling). and i seem to remember versions of lharc being distributed in (if you can believe this) .lzh files (sheesh! talk about a catch-22). sorry i can't offer u any help. lharc is just not robust enough (far too "delicate" if you ask me). perhaps the various factions maintaining it can come to terms and collaborate so that this mess will eventually get resolved. i believe there was a new version of lharc for unix posted to comp.sources.misc (which is archived on uunet.uu.net and elsewhere, if u have FTP access). u might give it a try. one of the flakier aspects of lharc (at least the unix version i have) is illustrated by this scenario: 1) i generally unpack uuencoded files which i save from news with the same name as the arc/lzh/zoo file name, without the extension (i.e. if the archive is "xxx.lzh" i save the uuencoded file with name "xxx"). 2) after uudecoding, i am left with files "xxx" and "xxx.lzh". 3) if i say "lharc v xxx" to make sure there is a readme file before i delete the original posted file (e.g. "xxx" in this example), lharc barfs, saying xxx is not an archive. it is not smart enuf to look for "xxx.lzh" unless i tell it to do so with "lharc v xxx.lzh". zoo, however IS smart enuf to append the proper .zoo suffix before it opens the archive. to be fair, i thing a) this is a trivial change (but i have to fix it myself, unless newer versions are so equipped), and b) i think arc has the same problem (don't quote me on that though). note that everything i post is arc'd (5.21) to make sure anybody can read it, no matter what (tos/dos/unix/vms/etc)... there, i feel MUCH better :-) -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com