rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] rdiff-backup 1.1.2 testing - problems


From: Ben Escoto
Subject: Re: [rdiff-backup-users] rdiff-backup 1.1.2 testing - problems
Date: Fri, 18 Nov 2005 23:21:07 -0600

>>>>> Kevin Horton <address@hidden>
>>>>> wrote the following on Tue, 15 Nov 2005 20:39:49 -0500

Hmm, I don't really know what could be the problem.  My one thought is
that there might be a problem with python's gzip on your system.  I've
written a little gzip script on your system, you can download it at:

https://savannah.nongnu.org/bugs/download.php?item_id=15006&item_file_id=3111

Once saved you can:

chmod 755 gzip-python
./gzip-python <file>

and it will work a bit like gzip, writing a compressed version of
<file> to <file>.gz.  So I'd be interested to see if you can compress
files (including large files, like 4GB+ files) that decompress to the
correct original files.

> Before this failure traceback, I only see Resource fork data lines,  
> with hex data.  Very, very, very long lines.  The last Resource fork  
> line just above the traceback is about 1,800,000 characters long.  Is  
> this expected?

I guess it depends on the size of the resource fork.  I forget how big
resource forks are supposed to be, but there was a discussion a long
time ago when they were added, and whoever added them apparently
thought that they would be small enough to put in the mirror_metadata
file.  Isn't there some quick way on Mac OS to tell how long a file's
resource fork is?

This resource fork error may also be a symptom of a corrupted
mirror_metadata file, so you may want to use --no-resource-forks when
testing, until the mirror_metadata problem gets fixed.


-- 
Ben Escoto

Attachment: pgplDDCGJO9mw.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]