On Thu, Oct 7, 2010 at 1:49 AM, Titl Erich <[email protected]> wrote:
> I guess this finding should give you something to chew on
Indeed! If I'm reading the hex dumps correctly, then, the first file
is padded at the beginning with exactly 28424 bytes of zero. The file
lengths differ by the same quantity. Can you verify that the files
are identical after that offset is removed?
I wondered if the zeroes could come from padding to a multiple of the
block size (presumably 32,768). Sort of!
>>> 14392979208 % 32768 # unreadable
28424
>>> 14392950784 % 32768 # readable
0
So the *readable* file is an even multiple of the block size (and may
include some trailing all-zero tar records for that purpose), while
the *unreadable* file is not. So this offers no clue as to where that
offset comes from.
Let's see if those extra bytes are coming from the server, or if
amrecover is adding them, somehow. Can you add the following patch to
Amanda/Recovery/Clerk.pm (you can just add the line in place, without
the "+")
diff --git a/perl/Amanda/Recovery/Clerk.pm b/perl/Amanda/Recovery/Clerk.pm
index 40c9ff1..f344893 100644
--- a/perl/Amanda/Recovery/Clerk.pm
+++ b/perl/Amanda/Recovery/Clerk.pm
@@ -330,6 +330,8 @@ sub _xmsg_part_done {
my ($src, $msg, $xfer) = @_;
my $xfer_state = $self->{'xfer_state'};
+ Amanda::Debug::debug("@@@ read a $msg->{'size'}-byte part");
+
my $next_label = $xfer_state->{'next_part'}->{'label'};
my $next_filenum = $xfer_state->{'next_part'}->{'filenum'};
also, please set
auth_debug 9
on the server *and* the client. Then do another run with amrecover.
The amrecover, amidxtaped, and (server-side) amandad debug logs will
then have sufficient information to determine how many bytes passed
through each component.
If I recall, there's no filtering (crypto or compression) going on, right?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
