D.B.Barratt@newcastle.ac.uk (Dave Barratt) (06/21/91)
I'm a bit confused regarding the different formats available for
archiving files e.g. arc, lharc, zoo etc. Is any one of these
formats more efficient or reliable than the others, if so does
this not make the others somewhat redundant? Is there any
compatibility between the different formats?
In other words which format should I be using to archive my
files?
Cheers,
Dave
*********************************************************************
Dave Barratt JANET: D.B.Barratt@uk.ac.newcastle
Computing Laboratory
University of Newcastle upon Tyne
UK
" A spacers not a spacer till his trod vac "
klute@tommy.informatik.uni-dortmund.de (Rainer Klute) (06/25/91)
In article <1991Jun21.152722.17873@newcastle.ac.uk>, D.B.Barratt@newcastle.ac.uk (Dave Barratt) writes: |> I'm a bit confused regarding the different formats available for |> archiving files e.g. arc, lharc, zoo etc. Is any one of these |> formats more efficient or reliable than the others, if so does |> this not make the others somewhat redundant? Is there any |> compatibility between the different formats? ARC: Fast, reliable and effective. Since version 6.02 arc can archive complete directories. Unfortunately it cannot store/extract dedicated files from a directory :-(. ZOO: Not as fast as arc but very reliable. The most flexible archiving system. You can put several versions of a file into an archive, associate comments with archive elements and much more. Reading the zoo manual is really worthwhile! Zoo archives need some more space than others. My favorite archiver for larger distributions with nested directories. I also use it to backup my program development directories because I can store several versions of the source files. LHARC: Slow and unreliable. It has become popular because it has the best compression factor. However, archiving and extracting is really slow. There are several not always compatible LHarc versions by different authors floating around. So if you don't have the right LHarc you might not be able to extract an archive at all. Just say NO. -- 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
ue@nathan.ruhr.de (Udo Erdelhoff) (06/27/91)
In <3564@laura.UUCP>, Rainer Klute writes: >LHARC: >Slow and unreliable. It has become popular because it has the best >compression factor. However, archiving and extracting is really slow. There >are several not always compatible LHarc versions by different authors >floating around. So if you don't have the right LHarc you might not be able >to extract an archive at all. Just say NO. You haven't ever used LHArc 1.1321, have you? Give it a try and start thinkig about using LHArc again... /s/ -- Udo Erdelhoff ue@nathan.ruhr.de Fido: Udo Erdelhoff on 2:245/52.1
klute@tommy.informatik.uni-dortmund.de (Rainer Klute) (06/27/91)
In article <A0b7mrze@nathan.ruhr.de>, ue@nathan.ruhr.de (Udo Erdelhoff) writes: |> You haven't ever used LHArc 1.1321, have you? Give it a try and start |> thinkig about using LHArc again... Whatever the advantages of LHArc 1.1321 might be (faster?), it does solve the problem of those many incompatible LHarcs. Using LHarc of whatever version could only under the following conditions be tolerated: - There is only one LHarc version at a time. - The source code is maintained by a single person or team. - The source code is completely written in C (no assembly "optimizations"). - The source code is suitable for most (better: all) machines and operating systems. -- 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
davidli@simvax.labmed.umn.edu (06/27/91)
In article <3580@laura.UUCP>, klute@tommy.informatik.uni-dortmund.de (Rainer Klute) writes: > Using LHarc of whatever > version could only under the following conditions be tolerated: Add to Rainer's list: - The source code and executable code should be Public Domain (ie. no calls for Shareware fees involved) One of the reasons I despise most of the LHarc versions is that their authors are trying to make a buck while they introduce incompatibilities. (The author of xlharc 1.2 excluded from this list...) -- David Paschall-Zimbel davidli@simvax.labmed.umn.edu
ralph@laas.fr (Ralph P. Sobek) (06/28/91)
Just a slight correction and addendum to the following. In article <3564@laura.UUCP> klute@tommy.informatik.uni-dortmund.de (Rainer Klute) writes: | | LHARC: | Slow and unreliable. It has become popular because it has the best | compression factor. However, archiving and extracting is really slow. There | are several not always compatible LHarc versions by different authors | floating around. So if you don't have the right LHarc you might not be able | to extract an archive at all. Just say NO. LHARC is *extremely* slow to make an archive, but it is usually considered as a fast extractor, in addition to its compression factor. I would just like to point out that sometimes ZOO creates a better compressed archive than does LHARC. -- 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 =============================================================================== Got a Mega 4 ST. Wishing it was a Mega STe! :-| Do I *really* want a TT? ;~#