EHLO
Greetings,
devels: rdiff-backup stores data by using industry standard "gzip". But
bz2 has better compression. Or even usage of 7zip, which is not
"industry standard" but everyone is using it, so it will become industry
standard sooner or later, and it has more aggressive compression than
all other zip algorithms (it has even multi-thread support, so SMP
kernels and multi-core systems can use advantage of it). PS: 7zip AFAIK
has library installed besides command-line tool `mc` - midnight
commander is using it) -> I'm not sure about .so library, but I'm really
sure that bz2 package _HAS_ library, I mean .so on unices, on windows,
there should be .dll as well).
would it be possible to implement bz2, or even 7zip ?
on windows installation (e.g. cygwin) can place dependency for
compression libraries...
Best,
VooDooMan
.
On 11. 8. 2010 20:00, Steven Willoughby wrote:
On 08/10/2010 04:16 PM, Robinson, Eric wrote:
"It's quiet."
"Yeah, too quiet. Gives me the willies."
"Me, too."
--
Eric Robinson
-----Original Message-----
From: rdiff-backup-users-bounces+eric.robinson=psmnv.com < at > nongnu.org
[mailto:rdiff-backup-users-bounces+eric.robinson=psmnv.com < at > nongnu.org]
On Behalf Of Robinson, Eric
Sent: Saturday, August 07, 2010 8:50 AM
To: rdiff-backup-users < at > nongnu.org
Subject: [rdiff-backup-users] Error "Unable to compare" BUT THEN "No
changesfound. Directory matches." What?
I've been using rdiff-backup for a while, but today was the first time I
tried using the --compare-hash directive.
First I get tons of these messages...
Warning: Metadata file has no digest for<file>, unable to
compare.
That's scary enough by itself. But then at the end it says...
No changes found. Directory matches archive data.
So if it can't compare, why would it say the directory matches?
I have been running rdiff-backup for a long time with the --verify
option which does something similar with no issues. The --compare-hash
option also seems to be working perfectly for me. Adding -v6 to your
command might be enlightening.
And what is the problem with the hash in the first place?
The hash should be stored in
$backup_dir/rdiff-backup-data/mirror_metadata.$date. Try looking at the
mirror_metadata snapshot previous to the current one (you should be able
to open it with zless or zcat). IIRC older versions of rdiff-backup
(like 1.0) didn't store this hash, so perhaps it is missing. If that
was the case then that would explain the warnings and the "No changes
found." is probably a bug since it didn't find any files that didn't
match (since all of them were skipped.)
It might work to use the --compare-full option if you haven't been
storing hashes.
Steven
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL:
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
