|
Posted by Mark Seger on October 21, 2004, 12:26 pm
Please log in for more thread options
I have a script that periodically copies a number of files from /proc to
a zipped file using this library. It's been working fine for over a
year and I've recently encountered a corrupted file. My first question
has to do with how the thing got corrupted in the first place and the
second question is why don't I get an immediate error when hitting the
corrputed data.
Now for some details.
Writing the file I simply do a
$file=Compress::Zlib::gzopen($filename,'ab') or error-handling-here
$file->gzwrite($data) or error-handling-here
periodically I flush the buffer with
$file->gzflush(2);
I don't report any errors when writing the file, but I also just noticed
on closer inspection that I'm not checking the return status from flush.
Could that be my problem? groan...
If I try to gunzip the file, it fails with a message that the file is
corrupted. If I zcat the file and redirect the output to another file,
I get a couple errors that the file is corrupted but it does continue
processing. However, the resultant file is clearly corruputed midway
through. If I read the file with gzreadline it eventually returns an
error, but not before returning a whole pile of corrupted records. Does
this mean that the data buffer was corrupted (maybe by gzflush) but
successfully compressed?
Is corruption related to the way I'm doing the flushing and if so what
could I have done to prevent this? Assuming I did trap the error (which
I will definately add to my code) is there a clean way to recover? My
current thought is I should just close the file and reopen a newer version?
-mark
|
|
Posted by Jim Keenan on October 22, 2004, 1:27 am
Please log in for more thread options
Mark Seger wrote:
> I have a script that periodically copies a number of files from /proc to
> a zipped file using this library. It's been working fine for over a
> year and I've recently encountered a corrupted file. My first question
> has to do with how the thing got corrupted in the first place and the
> second question is why don't I get an immediate error when hitting the
> corrputed data.
>
> Now for some details.
>
Is it the same file that gets corrupted all the time? Or perhaps does
it always occur at the same point in the process, say, the 17th file
gets corrupted?
jimk
|
|
Posted by Mark Seger on October 25, 2004, 9:28 am
Please log in for more thread options Jim Keenan wrote:
> Mark Seger wrote:
>
>> I have a script that periodically copies a number of files from /proc
>> to a zipped file using this library. It's been working fine for over
>> a year and I've recently encountered a corrupted file. My first
>> question has to do with how the thing got corrupted in the first place
>> and the second question is why don't I get an immediate error when
>> hitting the corrputed data.
>>
>> Now for some details.
>>
>
> Is it the same file that gets corrupted all the time? Or perhaps does
> it always occur at the same point in the process, say, the 17th file
> gets corrupted?
>
> jimk
no. I've been running this script on many systems, most almost every
day, for over a year and only experienced the corruption this one time.
Since the contents of /proc is constantly changing it's certainly
possible there was something in one of the lines I read from it that
triggered the corrpution but I wouldn't have thought so.
-mark
|
| Similar Threads | Posted | | Need help with Compress::Zlib code (inflation gives error) | November 17, 2005, 6:23 pm |
| Compress::Zlib installation | August 12, 2006, 7:25 am |
| Compress::Zlib unable to inflate | July 24, 2006, 3:52 am |
| LWP, timeouts and error handling | September 5, 2004, 3:31 am |
| perl dbi and RaiseError handling - is this a situations which won't raise an error? | November 25, 2008, 9:13 am |
| Remote.pm (File::Remote) error handling question | January 29, 2007, 12:57 pm |
| ANNOUNCEMENT: Compress::Bzip2 2.08 | May 11, 2005, 11:26 pm |
| Compress::Bzip2 needs work | April 20, 2005, 9:41 pm |
| ANNOUNCEMENT: Compress::Bzip2 2.08 | July 9, 2007, 3:51 pm |
| Proposed Module: Compress::AsciiFlate | March 10, 2006, 6:37 am |
|
XML Sitemap