On Thu, Sep 12, 2002 at 08:36:26PM +0200, Brian Jonnes wrote:
> On Thu 12 Sep 02 16:38, Niall O Broin wrote:
> > This is true but as a friend pointed out to me recently when I was having
> > some tape reading problems - if you get some bit errors reading a tar file
> > from a tape, most likely asll you will lose is the affected file. If OTOH
> > you get bit errors reading a gzipped tar file, you most likely will not be
> > able to read anything after the bit errors. Just something to be aware of.
>
> So... when, and how much work is it to get bzip2 used. Apparently it doesn't
> suffer from this problem?
When? As soon as someone (you?) comes up with the appropriate changes (to
make it an either/or), tests them, and submits them.
> If I were to replace (by hook or by crook) the COMPRESS_PATH to bzip2 would
> that work?
I scanned amanda-hackers and amanda-users archives on yahoo-groups for "bzip".
Among the relatively few hits I found one of my own replies (attached). It
was musing about how one could "dropin" bzip2.
Caveats, I never tried it, no one ever replied they tried it, and my musing
was based on 2.4.2. 2.4.3 may have some different or new parameters.
> And what is the opinion of the Right Way to do this?
Some of the archive postings mentioned the "right way" was to finish the
design and implementation of the FILTER-API. But I doubt that has progressed.
Is it a real, or theoretical, problem? I.e. has anybody experienced bit errors
in a gzip'ed document? For me the incidence is low enough that I don't feel a
need to use bzip2 for that extra protection. The value of your data may lead
to a different conclusion.
I looked at bzip2 for its higher compression ability compared to gzip. However
its slow execution on my systems made me lose interest. I don't even use the
"--fast" option of gzip because of reduced performance.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Looks like bzip2 could be a drop in. Configure looks for a GZIP
environment
variable for the path to gzip in preference to a search. Perhaps
define it
as "export GZIP=/usr/local/sbin/amzip" or wherever other amanda
executables
reside before doing the configure.
Then you could install gzip or bzip2 as "amzip" and test each one.
Base on the man pages on my Solaris system the options are similar.
They both take the the "-dc" option for decompression to stdout.
However, you may have to change some #define's in config.h.
/* Define to the exact path to the gzip or the compress program. */
#undef COMPRESS_PATH
configure may find it from $GZIP
/* Define to the suffix for the COMPRESS_PATH compression program. */
#undef COMPRESS_SUFFIX
".bz2" maybe?? But won't be the same for both bzip2 and gzip.
/* Define as the command line option for fast compression. */
#undef COMPRESS_FAST_OPT
/* Define as the command line option for best compression. */
#undef COMPRESS_BEST_OPT
Both take number options, -1 to -9,
But amanda seems to use --fast (aka -1) and --best (aka -9).
Changing this to define them as -1 and -9 should work for both.
/* Define as the exact path to the gzip or compress command. */
#undef UNCOMPRESS_PATH
Should be same as COMPRESS_PATH
/* Define as any optional arguments to get UNCOMPRESS_PATH to
uncompress. */
#undef UNCOMPRESS_OPT
Current seems to use -dc so no change should be needed.
For those who wish to try it, any reason this would not work?
