>>>>> Kevin Horton <[EMAIL PROTECTED]> >>>>> 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
pgp7w4KzjceQK.pgp
Description: PGP signature
_______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
