v069qqqc@ubvmsd.cc.buffalo.edu (Michael Carrato) (09/19/90)
I got Fish disk 362 from abcfd20 (a.k.a. 'the new xanth') and it seems
as if it was lharc compressed on an IBM, because all of the directory
seperators are backwards ('\' instead of '/'). So when I unpack it,
no directories are created, just a bunch of wierd files in the root
directory (i.e. 'foo\bar\readme'). Is the archive corrupt or are they
incompatible? By the way, I did use the -x switch.
Mike Carratoaduncan@rhea.trl.oz.au (Allan Duncan) (09/21/90)
From article <36782@eerie.acsu.Buffalo.EDU>, by v069qqqc@ubvmsd.cc.buffalo.edu (Michael Carrato): > I got Fish disk 362 from abcfd20 (a.k.a. 'the new xanth') and it seems > as if it was lharc compressed on an IBM, because all of the directory > seperators are backwards ('\' instead of '/'). So when I unpack it, > no directories are created, just a bunch of wierd files in the root > directory (i.e. 'foo\bar\readme'). Is the archive corrupt or are they > incompatible? By the way, I did use the -x switch. I think that the unix version is capable of doing this if you get the right set of compiler switches. Allan Duncan ACSnet a.duncan@trl.oz (03) 541 6708 ARPA a.duncan%trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!trl.oz!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.
Glenn Everhart 215 354 7610 Everhart@arisia.dnet.ge.com, (09/25/90)
I created ff362.lzh on an Amiga; I believe it was using LZ (one of the versions, probably 0.82). When I list the archive on our VAX VMS system, the directories come out separated with "/" characters. It's a mystery to me what the trouble is, but I've never been able to get msdos Lharc to produce an archive, and the filenames are too long to be produced from an MSDOS system; this should have been a giveaway. The file looks OK to me. Glenn Everhart
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/01/90)
Glenn Everhart 215 354 7610 Everhart@arisia.dnet.ge.com, writes: >I created ff362.lzh on an Amiga; I believe it was using LZ (one of >the versions, probably 0.82). When I list the archive on our VAX >VMS system, the directories come out separated with "/" >characters. I take it that isn't a VMS tree level separator; it's been a few years. > It's a mystery to me what the trouble is, but I've never been able >to get msdos Lharc to produce an archive, and the filenames are >too long to be produced from an MSDOS system; this should have >been a giveaway. The file looks OK to me. >Glenn Everhart I, too, have noticed a significant set of incompatibilities among the Lharc implementations on various platforms; in comparision, zoo is a miracle of compatibility (thanks, Rahul!). The BSD compilable Lharc recently posted to comp.sources.misc, if used in normal Unix mode, creates files completely unreadable by Amiga Lharc. If used in "compatibility" mode, it no longer archives a tree of files, but only one flat directory, it uppercases all the file names, and generally assumes the non-Unix world is an ugly MS-DOS universe. To recover the directory names on the Amgia requires that a text file containing the (mixed case) file names be stored with the files on the BSD side. Lots of luck if you wanted to port the directory structure. On the other hand, the BSD Lharc creates and recovers directory trees on the BSD box very nicely, and saves gobs of storage compared to compress or zoo. The Amiga Lharc adds files at the end of the archive, the BSD Lharc puts them into the archive in alphabetical order. The Amiga Lharc uses BSD type "-" flags, while the BSD Lharc uses zoo-expert-mode-looking switches without the "-"s. (You have to love that one.) The BSD distribution comes with source, the Amiga one does not. The Amiga Lharc creates files that can be unpacked on the BSD box, but when "l"isted, they show up on the BSD box with "generic" in the permissions part of the listing, which is OK. However, if you add a file on the BSD box to an Lharc-ive created on the Amiga, the whole archive is now unreadable on the Amiga (since the BSD box sloshes the files through its idea of appropriate structure in the course of alphabetizing them) even if the "g"eneric flag is used. This is a dreadful nuisance to me, since I use my BSD host site to unpack and uudecode lharc files from the Amiga archives on (still no new name, Tad?) "New Xanth" (I hear "Old Xanth" is on the scrap heap; perhaps you can kidnap the old name, since the hardware is no more?), and I want to store a copy of the first news article header to show me where I got the software. Since I can't add the header file to the lharc-ive on the BSD box, I have to port them to the Amiga separately, which means I have to name the header files with unique names where I normally just call them all "POSTER.sources" or "POSTER.binaries" when I do the same trick with zoo. (While I'm whimpering, did I mention that we temporarily, like for six weeks or so, lost zoo in the course of the upgrade? I will bring it up just as soon as we have a disk working (power supply needed) big enough to unpack the USENet source archives where the zoo source is kept. These _are_ interesting times.) LH, the "fast" assembly version of Lharc, is dependent on having arp.library in Lib:, which I wouldn't do for love or money, so it is essentially useless to someone trying to run a vanilla AmigaDOS distribution, as I do. Nor does the arp.library accompany the distribution, nor does the assembler source. Pfaugh! What made zoo work was one central person with source code control. Lharc has at least 5 independent threads of development, and each seems pretty blindered to their own piece of the elephant. Nice as the superior compression is, Lharc is essentially useless as a software portability tool, and until the developers get together and call a truce on incompatible archive formats, it's probably a _real_ good idea to go back to using zoo for sharing software, and only use Lharc to pack stuff for local storage benefits on the platform where it is going to be unpacked. Sad, since these, particularly the Amiga version once it gets alphabetical storage order working, have the potential to be really useful tools if only _one_ version that is ported to all platforms, rather than (at least) five incompatible versions, could exist. Sigh. If all the distributions were accompanied by source code, some clever person, or even I, could be expected to grow impatient with the current mess and merge the versions and capabilities. In particular, a SYSV port is desperately needed (but not by me, my host site just upgraded to a BSD system; there may be a God after all). There's a pretty clear lesson here: go GNU! So, way out there in inaccessible Fido net, out in far Oz, over in Japan, in the bowels of MightySimpleminded-DOS, wherever the BSD version was done, could you guys please get your act together? Please? Thanks, I guess. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
jpr@jpradley.uucp (Jean-Pierre Radley) (10/04/90)
In article <1990Oct1.032937.5696@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > Sigh. If all the distributions were accompanied by source > code, some clever person, or even I, could be expected to grow > impatient with the current mess and merge the versions and > capabilities. In particular, a SYSV port is desperately needed > (but not by me, my host site just upgraded to a BSD system; > there may be a God after all). There's a pretty clear lesson > here: go GNU! I'm coming late to this discussions, as I just got my feed. I'm running SCO Xenix 2.3.2, which also calls istelf "System V". The lharc I've got here ix v 1.02 which was mailed to me from Japan, and didn't require too many hacks to get around the BSDisms.
ripley@opal.cs.tu-berlin.de (Hans-Ch. Eckert) (10/08/90)
Hello. I also have these compatibility problems, although they don't hit me that hard. At least I could use all archives so far. On my home-platform (Atari ST) I have three different versions of lharc with each one behaving different. This is annoying at least ! Greetings, RIPLEY -- Greetings from RIPLEY | UUCP: ripley@tubopal.UUCP (ripley@opal.cs.tu-berlin.de) Hans-Christian Eckert | ...!unido!tub!opal!ripley (Europe) D-1000 Berlin 30 | ...!pyramid!tub!opal!ripley (World) Regensburger Str. 2 | BITNET: ripley%tubopal@DB0TUI11.BITNET (saves $$$)