Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!pmafire!uudell!bigtex!texsun!newstop!grapevine!panarthea!koreth From: koreth@panarthea.EBay.Sun.COM (Steven Grimm) Newsgroups: comp.sys.atari.st Subject: Re: Major Problems Unpacking 'lzh' Files Keywords: archivers lharc arc zoo banter Message-ID: <742@grapevine.EBay.Sun.COM> Date: 9 Jan 91 02:50:15 GMT References: <10472@lanl.gov> <1991Jan08.061722.26635@convex.com> <1991Jan8.153539.19118@wam.umd.edu> <1991Jan09.010526.15973@convex.com> Sender: news@grapevine.EBay.Sun.COM Lines: 69 In <1991Jan09.010526.15973@convex.com> rosenkra@convex.com (William Rosencranz) writes: >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. Whose "compress" are you using? Lharc usually does at least 10% better than tar/compress on all the systems I've used. To wit: Xsun (the MIT X11R4 server, SPARC executable): -rwx------ 1 koreth 811008 Jan 8 18:17 Xsun -rw------- 1 koreth 499097 Jan 8 18:22 Xsun.Z -rw------- 1 koreth 406469 Jan 8 18:17 Xsun.lzh omega (a fantasy roleplaying game, source code only): -rw------- 1 koreth 318708 Jan 8 18:33 omega.lzh -rw------- 1 koreth 1081344 Nov 14 1989 omega.tar -rw------- 1 koreth 389043 Nov 14 1989 omega.tar.Z 75dpi (the X11R4 75DPI font directory): -rw------- 1 koreth 741754 Jan 8 18:41 75dpi.lzh -rw------- 1 koreth 2703360 Jan 8 18:37 75dpi.tar -rw------- 1 koreth 801720 Jan 8 18:39 75dpi.tar.Z >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. Self-extracting lharc archives can be fiddled with with UNIX lharc, though if you do much to them, they lose their self-extractingness (?). The virus argument is somewhat valid -- after all, it is one more program you wouldn't otherwise run -- but cautious users can still use lharc on its own to extract suspicious archives. Lharc/UNIX handles file ownership and permissions. I don't think this is true of zoo. (The extra information is ignored on non-UNIX systems; there is a field in the lharc headers which says, "I have extra information about this file, and it's at this place in the header and is this long.") >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. There was an excellent version of lharc on alt.sources not too long ago. I can post it to comp.sources.atari.st if there's interest. It's the version I use to repack stuff in the sources and binaries groups, and seems to be compatible with all the ST versions in use nowadays. >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)... Which is mostly the reason comp.sources.atari.st isn't in shar format any more. Shar files turned out to be less portable than uuencoded archives of various sorts. The vast majority of people who responded to my survey told me to get rid of the shar format. Anyway, I thought it was important to inject some hard numbers into this argument. I think my examples are pretty typical of the sorts of things people are likely to compress. My opinion, in case it's not painfully obvious by now, is that lharc has enough advantages to warrant using it almost all the time (in fact, I use it instead of tar/compress to archive most of my UNIX sources.) I agree that it'd be nice if it were a bit faster, but you can't have everything. Not in version 1.0, anyway. --- " !" - Marcel Marceau Steven Grimm Moderator, comp.{sources,binaries}.atari.st koreth@ebay.sun.com ...!sun!ebay!koreth