wrs@infidel.lanl.gov (William R. Somsky) (01/06/91)
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. I've been downloading files to my ST via Z-modem, and 'arc' files have unpacked with no problem. When I try to unpack 'lzh' files, however, the various unpackers keep choking on the files---usually some sort of CRC or CRC-header error. I've tried several different 'lzh' de-archivers as well as several different 'lzh' files---no go. In particular, I have gotten the "starter" package from atari.archive, supposedly the 'recommended' set of de-archiving tools, and have been able to get LHarc 1.02 from this. But LHarc 1.02 still chokes on any 'lzh' file I give it. (As a size note, arc602 from the "starter" package works fine, so it's probably NOT a problem of unpacking the "starter" archive wrong.) Does anyone have any idea what's going on here?!? Since so much stuff is 'lzh' packed, I'd really like to be able to unpack them. Please E-mail your responses, since I havn't been reading news too often recently. Thanks in advance, -- ------------------------------------------------------------------------ William R. Somsky Center for Nonlinear Studies ; MS-B258 wrs@falcon.lanl.gov Los Alamos National Lab ; Los Alamos NM 87545
klute@tommy.informatik.uni-dortmund.de (Rainer Klute) (01/07/91)
Unfortunately there is a whole bunch of LHarc versions and programs out there. Most of them are uncompatible, at least with LHarc variants running under Unix. I don't know what people find so remarkable at LHarc (except the compression factor). Now for the question: The only LHarc version I have found useful so far is "LHarc 1.02 based on MSDOS LHarc 1.13", ported to the ST by Bill Shroka (bjsjr@ncoast.org). With this program I had no problems unpacking LZH archives. -- Dipl.-Inform. Rainer Klute klute@irb.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ Tel.: +49 231 755-4663 D-4600 Dortmund 50 |\|\ Fax : +49 231 755-2386
piet@cs.ruu.nl (Piet van Oostrum) (01/07/91)
>>>>> In message <10472@lanl.gov>, wrs@infidel.lanl.gov (William R. Somsky) (WRS) writes:
WRS> I've recently gotten back into using my ST, and have been trying
WRS> to download various files from atari.archive.umich.edu, but I'm
WRS> having MAJOR difficulties unpacking 'lzh' files.
WRS> I've been downloading files to my ST via Z-modem, and 'arc' files
WRS> have unpacked with no problem. When I try to unpack 'lzh' files,
WRS> however, the various unpackers keep choking on the files---usually
WRS> some sort of CRC or CRC-header error. I've tried several different
WRS> 'lzh' de-archivers as well as several different 'lzh' files---no go.
Note that zmodem usually does not recognize .lzh as an extension for binary
files, whereas it does recognize .arc. Maybe the files have been downloaded
in ASCII mode. I always download files in binary mode by default, even
ASCII files. (I download from Unix, and I can get the CR/LF characters with
a simple text editor).
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet
Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete')jhenders@jonh.wimsey.bc.ca (John Henders) (01/08/91)
In <2908@laura.UUCP>, Rainer Klute writes: > >Now for the question: The only LHarc version I have found useful so far is >"LHarc 1.02 based on MSDOS LHarc 1.13", ported to the ST by Bill Shroka >(bjsjr@ncoast.org). With this program I had no problems unpacking LZH >archives. I concur. LHarc1.02, recently posted on comp.binaries is the most stable version I've found. Some versions appearantly don't under- stand lower case file names in the arc. This is often the reason for corrupted header messages. LHarc does offer a significant difference in packed size. It probably would be the new standard if the versions weren't so incompatable. > >-- > Dipl.-Inform. Rainer Klute klute@irb.informatik.uni-dortmund.de > Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet > Postfach 500500 |)|/ Tel.: +49 231 755-4663 >D-4600 Dortmund 50 |\|\ Fax : +49 231 755-2386 -- John Henders jhenders@jonh.wimsey.bc.ca Vancouver,B.C. or jhenders@wimsey.bc.ca or ubc.cs!van-bc!jonh!jhenders
boyd@mailer.cc.fsu.edu (Mickey Boyd) (01/08/91)
I am impressed with Unlzh v1.72 (available from atari.archive). It is
very fast, and installs as an application quite nicely. I have yet to have
a problem extracting something with it.
--
Mickey R. Boyd | "God is a comedian playing to an
FSU Computer Science | audience too afraid to laugh."
Technical Support Group |
email: boyd@fsucs.cs.fsu.edu | - Voltaire rosenkra@convex.com (William Rosencranz) (01/08/91)
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
davidli@simvax.labmed.umn.edu (01/08/91)
In article <1991Jan8.153539.19118@wam.umd.edu>, dmb@wam.umd.edu (David M. Baggett) writes: > But the worst peroblem with > zoo is its brain-damaged syntax w.r.t. subdirectories.... > These days archiving subdirs should be the DEFAULT. Well, there's always the command line zoo -restore archive.zoo It's worked quite nicely for me. The other 'flaw' I see with the various LHARC, LZH, UNLZH programs is this: With the exception of ports like LHARC 0.5beta, et al, almost EVERY single archiver/unarchiver using the LHARC protocols is ShareWare. This bothers me, seeing that both ARC and ZOO were released as free-of-cost software, and the original protocols for LHARC didn't cost anything either. (I'm speaking non-commercially here, I'm well aware of SEA's commercial charges for ARC, as an example.) -- David Paschall-Zimbel davidli@simvax.labmed.umn.edu
Bryan_Jones_Woodworth@cup.portal.com (01/09/91)
Let me add to the discussion and say LZH is the best compression algorithym I have ever come across. I have had ZERO programs unlzhing files. However, once when I LZH'd a file it was a bad archive. don't ask me how.. But now I test my LZHives in UNLZH 1.7 before uploading to make sure that the LZH is good. Every time it is. I think I made a small error using it that first time which caused an error. LZH compacts the best. Until a ZIP with the imploding comes along, we should stick with LZH. I think there is a LGS shell which supports LHarc, so if you can't understand a command line then try that. UnLZH1.72 should be THE standard for extracting LZHives. It works cleanly and well. Try it, available on atari archive. Bryan_Jones_Woodworth@cup.portal.com
rosenkra@convex.com (William Rosencranz) (01/09/91)
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// <file> 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
koreth@panarthea.EBay.Sun.COM (Steven Grimm) (01/09/91)
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
jhenders@jonh.wimsey.bc.ca (John Henders) (01/09/91)
Re: Archiver Wars.
I've noticed Lharc1.2 is faster when you give it more memory. On
a friends one meg machine, it is noticably slower than on my 4 meg.
Has anyone compiled the unix source version to run under MiNT yet.
Then we wouldn't have to worry about speed.
--
John Henders jhenders@jonh.wimsey.bc.ca
Vancouver,B.C. or jhenders@wimsey.bc.ca
or ubc.cs!van-bc!jonh!jhendersroland@tuvie.UUCP (Inst.f.Allg.Elektrotechnik) (01/09/91)
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. I found that you need three or more different LHARC programs to decode the files for the Atari ST in comp.binaries.atari.st and at atari@atari.archive.umich.edu. If it does not work with one, just try another one. It is going to have the spirit of an adventure game... :-) I would like to see only ARC, ZOO, or Z files. There has never been any problem with these. _ Roland Schreier |_) _ | _ _ _| Technical University GusshausStr 27-29 | \ (_) | (_| | | (_| of Vienna in Austria A-1040 Wien schreier@eaecl1.una.ac.at Tel +43 (1) 58801 3838 Austria - Europe roland@tuvie.tuwien.ac.at Fax +43 (1) 5052666
rosenkra@convex.com (William Rosencranz) (01/10/91)
In article <1991Jan9.090428.29529@wam.umd.edu> dmb%wam.umd.edu@uunet.uu.net (David M. Baggett) writes: >>>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... >It's DOS (and therefore, for compatibility, TOS) that has the file >limit restriction. Only 113 files in a FAT. Or is it 112? In any >case, don't ask me why. i thought this restriction was only for the root directory of a disk, not subdirectories. but my memory, as usual, is fuzzy, and i have no way right now of verifying this. i know u can have more than 113 files in a hd partition, though i can't be sure if u can have more than 113 files in total on a floppy, even if they are in directories. easy enuf to test, however. are u saying that lharc has a restriction of 113 files in one of its directories because a user may potentially unpack it in the root dir and hence have problems? if that is the case, then all archivers will have the same problem. since i have not unpacked an archive in a root dir for years, i have never seen this. and i would guess that since most archives do not have this many files anyway (perhaps TeX fonts is an exception), this would probably rarely cause any problems. how does lharc deal with this? does it restrict u when creating the archive? and if so, is this also in the unix version? i have no idea how this works with arc/zoo either. just curious... >>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 guess I'm just hallucinating, then. no, dave, it just might be the files i tested and the date i tested them (when lharc just came out, like a year ago or so). i tried files ranging from 1k to 120k, text, programs (.ttp), and some binary files (16-bit sound samples). i thought it was reasonably comprehensive test, but it could have been an anomoly, from what i have seen you guys saying the last couple of days. it could also be that the compression itself improved from 0.62 (or whatever it was) to now. i do know, however, that no matter what file was compressed, it was REAL S-L-O-W at *packing*. i mean at least 2x slower. i distinctly remember lharc taking 6 min on a file that zoo did in around 2 min. still, it was a long time ago, so this is more of an impression than fact. >>> [self-extracting archives are great] >> >>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. > >In the case of SFX, I don't see how this is relevant. It's not like >an "autoexec.bat" is stored in the archive, it just has a 3K hunk >of code to extract the archive from the appended LZH file data. >The self-extracting part doesn't have any special power. This is no >more prone to virus-spreading than any other form of archiving. it is one more program to run, and extremely easy to fiddle with. from what i know about these archives, it is just "cat unpacker archive >file". is there any software to do checksums or compares on those 3k hunks? is the source to that 3k hunk PD? it would make me feel a little safer at least. i am reluctant to run any software i do not compile myself, if at all possible. i can trust an archiver, but not necessarily a self-extracting archive. are there tools available to strip this thing off (yes, i just remembered seeing one...never mind...). >Like I said, I'm running LHarc under Ultrix. Many ST owners, however, >don't use Unix and don't want to. Maybe the WILL learn the hard >way that Unix is IT, but that doesn't change the current situation, >which is that a lot of ST owners find Unix confusing and needlessly >complex. (Heck, a lot of ST owners still don't want multitasking.) well, maybe i am more of a unix bigot than i thought. also i like to try and look to the future, rather than the here and now - another thing that gets me in trouble :-). >The other problem is that many Atari owners seem to be quite isolated from >the Unix world. I'm not talking about Usenet folks, but rather the >people who have their ST's to do some word processing, play games, and agreed. but a well designed system will work no matter what knowledge level a person may be at. ok, ok, uncle. i'll quit my moaning on this and get the latest unix version. i may even hack it up to my liking (yet another version!). and i promise to broaden my scope to include non-technical people from now on :-)... adios... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
bjsjr@NCoast.ORG (Bill Shroka) (01/10/91)
In article <1991Jan8.122616.1@simvax.labmed.umn.edu> davidli@simvax.labmed.umn.edu writes: >The other 'flaw' I see with the various LHARC, LZH, UNLZH programs is this: > > With the exception of ports like LHARC 0.5beta, et al, almost EVERY > single archiver/unarchiver using the LHARC protocols is ShareWare. > This bothers me, seeing that both ARC and ZOO were released as > free-of-cost software, and the original protocols for LHARC didn't > cost anything either. (I'm speaking non-commercially here, I'm well > aware of SEA's commercial charges for ARC, as an example.) Xlharc, formerly LHarc 1.02, has never been anything but free-of-cost. I don't believe in porting free software and then deciding I should be paid for it. >David Paschall-Zimbel davidli@simvax.labmed.umn.edu -- -------------------------------------------------------------------------- Bill Shroka bjsjr@NCoast.ORG ncoast!bjsjr@usenet.INS.CWRU.Edu
jvt@its.bt.co.uk (John Trickey) (01/10/91)
In article <742@grapevine.EBay.Sun.COM> koreth@panarthea.EBay.Sun.COM (Steven Grimm) writes: > .... >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.") >..... Yes - but *badly* ! Perhaps its the originators fault - I've never bothered to look - but it always makes the files owned by root. Great(?) if you're SU but naff if you're not. Luckily it causes me no problems - just hassle but I can imagine it could seriously inconvenience some (most?) users where they cannot use root access. Lets remember we're talking about a PC type of archiver - UID means nothing here so why have it. Personally I prefer zoo but it *does* have its problems. I have never encountered any with the unix version (& I use that to transport all my archives to my ST because of a problem with the FD program here) but the ST version refuses to compress some files (usually binary). In this case I use arc which copes competantly but with less compression. John. -- John Trickey <jvt@its.bt.co.uk> || ..!mcsun!ukc!axion!its G4REV @ GB7SUT Voice: +44 21 333 3369 #include <std/disclaimer>
ekrimen@ecst.csuchico.edu (Ed Krimen) (01/11/91)
dmb@wam.umd.edu (David M. Baggett) writes: - Like I said, I'm running LHarc under Ultrix. Many ST owners, - however, don't use Unix and don't want to. Maybe the WILL learn the - hard way that Unix is IT, but that doesn't change the current - situation, which is that a lot of ST owners find Unix confusing and - needlessly complex. (Heck, a lot of ST owners still don't want - multitasking.) Dave, could you briefly describe a little about Ultrix, its availability (PD or commercial), system requirements, et al? Thanks. -- Ed Krimen ............................................... ||| Video Production Major, California State University, Chico ||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661 / | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0
dmb@wam.umd.edu (David M. Baggett) (01/11/91)
In article <1991Jan10.181920.16154@ecst.csuchico.edu> ekrimen@ecst.csuchico.edu (Ed Krimen) writes: >>dmb@wam.umd.edu (David M. Baggett) writes: >> >>- Like I said, I'm running LHarc under Ultrix. > >Dave, could you briefly describe a little about Ultrix, its >availability (PD or commercial), system requirements, et al? Thanks. Oops, I didn't mean to give the impression that Ultrix is an ST OS; it's not. It's running on the DecStations here and I assume it is a DEC product. It's basically like BSD Unix. I don't know the techincal details w.r.t. differences between Ultrix and Berkeley Unix. Dave Baggett dmb%wam.umd.edu@uunet.uu.net
Roger.Sheppard@bbs.actrix.gen.nz (01/11/91)
<1991Jan09.010526.15973@convex.com> <1991Jan9.090428.29529@wam.umd.edu> Sender: Followup-To: Distribution:world Organization: Actrix Information Exchange, Wellington, New Zealand Keywords: archivers lharc arc zoo banter banter banter Comment-To: dmb%wam.umd.edu@uunet.uu.net The limit of 112 files with LZH, well one of these Programs has a switch for 500 files, also Disks can be formated far greater than the 112 limit I have seen a German formater that lets you set the Directory limits I use Usenet but do have any access here in NZ. for the SHAR/TAR and Z I do find ZOO a bit of a problem and also LZH, ARC 602 is very good but from what I here ZIP would be the Fastest, but then again we don't have that, unless you bye the DCUTILS, so Please don't SHAR,TAR or compress any Binary files, we here in NZ could never get them, even the uudecode that I use was writen by the Sysop of the Unix System that I am using, so Please think of the many others that use Usenet that are not Unix mad, I for one can't stand it :-)... -- Roger W. Sheppard 85 Donovan Rd, Kapiti New Zealand...
Alex.Valdez@bbs.actrix.gen.nz (01/11/91)
>It's DOS (and therefore, for compatibility, TOS) that has the file >limit restriction. Only 113 files in a FAT. Or is it 112? In any >case, don't ask me why. No, there is no limit of 112 to the number of files in a directory - it's the GEM desktop that refuses to display more than that number. It seems that it reads the filenames into a buffer and sorts them to display by name (or type or size or date). -- Alex Valdez
Roger.Sheppard@bbs.actrix.gen.nz (01/11/91)
<1991Jan09.010526.15973@convex.com> <742@grapevine.EBay.Sun.COM> Sender: Followup-To: Distribution:world Organization: Actrix Information Exchange, Wellington, New Zealand Keywords: archivers lharc arc zoo banter Comment-To: koreth@panarthea.EBay.Sun.COM Thank you for a sensible reply to this LHZ debate, I don't think for one that file limit is valid as one has a switch for 500 files, also this Virus craze, how do you get a Boot Sector virus in a SFX file ??? Note: 100% of all viruses here in NZ are of the Boot sector type, so I can't se that getting into a SFX files, Please correct me if I am wrong I help on a BBS here in NZ and I do upload all my files that are on there are LZH ones, this gives a better storage space and a better dnload/upload time. Thanks for your binaries, Please keep to the same format, we would not be able to get them if changed to these Unix standards... -- Roger W. Sheppard 85 Donovan Rd, Kapiti New Zealand...
GERLOFF@tubvm.cs.tu-berlin.de (Olaf Gerloff) (01/15/91)
In article <1991Jan10.181920.16154@ecst.csuchico.edu>, ekrimen@ecst.csuchico.edu (Ed Krimen) says: > >Dave, could you briefly describe a little about Ultrix, its >availability (PD or commercial), system requirements, et al? Thanks. > >-- Hello Ed! Ultrix is DEC's implementation of UNIX. It is based on 4.2 BSD. It runs on the VAX and on DEC-Workstations like the 3100 and the 5100. Greetings, Olaf
ralph@laas.fr (Ralph P. Sobek) (01/15/91)
Hate to jump into this long discussion but ... In article <1991Jan8.154406.24146@terminator.cc.umich.edu> weiner@terminator.cc.umich.edu (Jeff Weiner) writes: | Lharc for unix is flakey, this is true. I use unlzh11.arc (from archivers) | on my ST and have never had problems. If someone has a good copy of | lharc for unix, please send me a copy. (Mike, I'll send you one too :) ) First of all, I am having better luck with LHarc on our Sun SPARC, than on my Mega ST at home. I usually test all archives before downloading, and I re-test again on my ST. I have never gotten *any* version of the UNLZH* programs to work. Even with all ACCs thrown out! I guess that UNLZH* must be doing something non-standard since this happens on French TOS 1.0 and 1.2. I usually use LHarc 1.02 on my ST. Whatever it refuses (and that does happen!) gets sent to LHarc 1.13B (of course, it refuses files accepted by version 1.02), and even once I've had to use the binary patched version of LHarc 1.13 (I believe the B becomes an M) for one file! SO, I AGREE WWHEN THEY SAY THAT LHARC IS FRAGILE!!!! | >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. | | Close one to call here. I don't have any figures (yet), but I'd dare | to say it's a bit more significant than that. Why not use the new ARC 6.02 (other than its 'Print' bug)? It's better than ZOO and its faster than LHarc. Unfortunately, it does *not* yet run under Unix, as far as I know. Someday, when I have time I'll post the statistics that I have on the subject. COMPRESS together with TAR is a viable alternative for Atari STs. Cheers, -- Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!laas!ralph If all else fails, try: sobek@eclair.Berkeley.EDU =============================================================================== THINK: Due to IMF & World Bank policies 100 million Latin American children are living, eating, and sleeping in the streets -- Le Monde Diplomatique