Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!convex!rosenkra From: rosenkra@convex.com (William Rosencranz) Newsgroups: comp.sys.atari.st Subject: Re: Major Problems Unpacking 'lzh' Files Keywords: archivers lharc arc zoo banter Message-ID: <1991Jan09.010526.15973@convex.com> Date: 9 Jan 91 01:05:26 GMT References: <10472@lanl.gov> <1991Jan08.061722.26635@convex.com> <1991Jan8.153539.19118@wam.umd.edu> Sender: news@convex.com (news access account) Organization: Convex Computer Corporation; Richardson, TX Lines: 160 Nntp-Posting-Host: convex1.convex.com In article <1991Jan8.153539.19118@wam.umd.edu> dmb%wam.umd.edu@uunet.uu.net (David M. Baggett) writes: >zoo is the worst of the archivers I have seen in terms of compression ratios. zoo is not worse than arc 5.21, which is far and away the most popular micro computer archiver on the planet, i suspect (probably because it has been around so long). the best archive system i know of for now and probably the moderate future is compressed tar files, though this is obviously geared for unix. still, unix IS begining to dominate the computer world as the OS of choice, at least for small systems and will continue to do so for a long time, i suspect. and there are excellent versions of both GNU tar and compress 4.3 available for the st now. > But the worst peroblem with >zoo is its brain-damaged syntax w.r.t. subdirectories. If you don't >unarc with zoo x// then you don't get the tree structure, even i have no trouble with zoo x.// archive at all. and u un-zoo zoo files :-) >If you use Jon Harris' unlzh.prg, it will automatically extract full is there a unix/vms/whatever version of this? i want to look at it BEFORE i take the (excruciating) time to download it to my ST. >pathnames for you. Not that this is CRUCIAL if there are more than >113 files in the archive, since directories can only have 113 files >in them, max. does zoo have this file limit restriction? i KNOW tar does not... >Re: Your points: >1) It's slower than zoo to archive, but quicker to unarchive. Archiving > only has to be done once. Since most people (in fact, all except one) > will be UNpacking, it's safe to say that to save "valuable time" we > should minmize UNpacking time. what? i am constantly making archives. but then i am a programmer with like 10+ MB or source (archived) on my hard disk. one application alone that i have written for the st is over 1.6 MB (that is just the source code). i suspect "most people" DO create archives and that, at least for those of us that do, PACKING time is just as significant as unpacking, probably more so, in fact, since we do more packing than unpacking. and those of us who write the software you use (for free), should at least be heard. >2) I wouldn't say "marginally better". The HacMan II distribution (+700K) > compressed to 257K with LHarc and 335K with zoo. This is not > ideosyncratic; I saw similar ratios when I was trying to decide what > archiver to use for software distribution. Zoo came in last place > consistently. (Vs. Lharc and Arc 6.x) i performed similar tests on a variety of file sizes/types and found that lharc was 5-10% smaller, but 50% slower (or more :-() at creating the archives. i buy bulk disks for $0.80 each. that means a savings of $0.04 to $0.08 per disk. if it takes 1 minute longer to CREATE an 700k archive using lharc, then somebody making $20/hr has lost $0.33 in TIME. for 100 disks that is a net loss of at least $25 or over 1 hr of time vs a savings of $4 on disks. i am sorry, but i personally value MY time more than the few pennies i save on disks. and i think it takes more than 1 min longer to lharc vs zoo or arc 5.21. i don't recall testing arc 6.x. i have not even attempted to add in a cost for the "aggravation factor" waiting for lharc to finish its lethargy... > Besides that, you can > make self-extracting LZH archives, so it really doesn't matter if > people have unlzhers or not. NO, NO, NO, NO!!! i don't like the idea of self extracting archives because it just makes it more likely to pick up a virus this way. and i can't unpack one of these on any other system than an ST, so it is extremely non-portable. i often use source posted to other groups on both unix and st. if they post self extracting archives for their machines (i.e. mac or amiga), there is no way to unpack these without the machine. a GIANT leap BACKWARDS in open systems and portability and sharing of software. PLEASE DO NOT ADVOCATE THIS!!!! note that the amiga news groups have standardized on shar files for source (including uuencoded binaries in shar files). minix is more of a hodgepodge, but generally shar or uuencoded compressed tar files. but then they are not restricted to 8+3 file names. ibm binaries group uses zoo (and there a HECK of alot more of those around than STs). i ignore mac stuff (they use binhex or some other less attractive scheme). i think the amiga guys are closest to my concept of ideal, which is more like unix than msdos. funny, i always thought one of the big attractions for the ST is that very early on it was possible to make it at least look like unix. and if u complain that u do not use unix (now), i can only say that within a few years, you WILL be using it. so why not get on track now? >Look, zoo is worse than arc 6, so why would you want to standardize to >zoo, of all things? how is it "worse"? and i did not suggest standardizing on zoo at this point. please consider ALL aspects of archiving, not just size. that is stupid. zoo handles directories (not as cleanly as i would want, either, so don't think i am advocating zoo, really). > You'd be better off using tar and compress. excellent idea. i keep tons of stuff (100's of MB) this way under unix. and some things on my st as well. the big problem is dealing with the name of the archive (extension) because of tos. but tos compress tries to do a rational job by using "z" as the last char of the extension. this does not help when u have a unix file like "whatever.tar.Z", which must be renamed to (say) "whatever.tz". hence u always run into a problem with the name. >(I am serious there.) so am i... >There are perfectly stable versions of LHarc on >atari.archive. i don't care about stable versions of lharc on the ST. i need a decent version for unix. the one i have is still somewhat flakey (IMHO) compared to the unix version of zoo. i need to be able to look at the archive and scan the documentation BEFORE i decide to download the megabytes of files just to see if i want it or not. i get news at work, not via uucp at home. and as i mentioned, there is only one central source for zoo, not 2 or 3 (or more?) like lharc, which causes confusion at best. i could live with just one "official" version of lharc, if u could kindly arrange that. that includes lharc for unix, tos, msdos, vms, etc. >I suggest you get a more recent version of Lharc. I compiled it >(the one on atari.archive) for Ultrix and it has no such problem. This >is NOT an inherenet flaw in Lharc, and certainly has NOTHING TO DO with >the LZH protocol. the lzh protocol is not the problem. the user interface is, however. i will, however, get src for the version u mention here are try it on my unix system to see if it is any better. there are more things to consider than simply compression ratio (or even speed, for that matter) each time we change formats. if a new compression program was released say every 6 months, each time improving only the compression ratio, but changing file formats, would we change our standards every 6 months? i certainly hope not. ok, enuf said on this topic. move along. maybe we can at least consider compressed tar files or compressed shar files as an alternative, though again it seems too late at this point. the problem with shar files is there are so many different types, so it would be difficult to do it (efficiently) without unix (or at least not without the raft of things that go into shar files, viz. sh/sed/cat/wc/test/echo/et al)... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com