At 13:55 2002-01-22 -0700, James C. McMaster (Jim) wrote:
I keep a backup of all my messages in a .gz file, in case of procmail errors.
Every so often, I get an error writing to the file...maybe 5-10% of the
time. I do lock the file, and turned on VERBOSE logging, but still cannot
figure out what is happening.
FTR, with gzip 1.2.4 (the current version), and I'd expect all earlier
versions as well, you have better than a 1 in 32K chance for EACH block on
any individual incremental decompression operation to NOT decompress
further, resulting in loss of data.
I provided a patch to Jean-Loup Gailly in November 2001 after running into
this bug one too many times. I recompress my gz files before moving them
to long term archives, and occasionally noted recompresses which were
DRAMATICALLY smaller than their original files - this due to the
termination of the decompress when the incremental compression block falls
on a buffer boundary - I finally got tired of manually "fixing" it
(chopping the stream into pieces), and investigated the source for the
cause. Seems remarkable that a tool so widely used (and for so long) has
such a glaring bug in the buffer operations - but it only rears it's head
when you're incrementally compressing things, not when they're compressed
as one stream.
My recipe is:
... you don't indicate what $GZIP is defined as, and whether it is in the
path or not...
:0 c:$MAILDIR/.lock.backup.gz
*!^Subject:.*\*COMIC\*
|$GZIP -9fc >> $MAILDIR/backup.gz
VERBOSE = 0
A section of my mail log with the error is:
Do this: don't use "$GZIP" and instead pipe to "gzip" (or the longhand
path). Any difference? I had troubles using a variable with gzip at one
point - basically, it appeared that unless it was a fullly qualified path,
using the variable would result in the path NOT being traversed to find the
program. Defining it to be the full path to the program would work however.
This shows three invocations of gzip, with the second having the problem.
Can anyone tell me what is going on?
I really can't say - try it longhand and see if it remains.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail