Hi Dustin > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Dustin J. Mitchell > Sent: Wednesday, October 06, 2010 6:03 PM > To: [email protected] > Subject: Re: FW: amrecover bug? > > On Wed, Oct 6, 2010 at 10:10 AM, Jon LaBadie <[email protected]> wrote: > > Again, if trying from the server, might this be yet another tar > > version incompatibilities? > > This is unlikely, but worth checking out all the same - can > the version of tar that amrecover is using successfully > extract the amfetchdump'd tarfiles?
Client and server are clones from the same stem, so I am pretty sure the tar
versions are the same.
>
> If so, can you "wrap" that tar in a shell script so that it
> also writes the datastream to a permanent file, and then
> compare the known-good and known-bad datastreams to see
> what's going on? Your hypothesis about a difference in
> offsets makes sense, but maybe there's just random corrupt
> data in there. It would be good to know at what offset the
> corruption begins.
I replaced /bin/tar on the client by a simple script
#!/bin/sh
cat > /backup/amanda/datastream
exit 0
And so wrote the datastream to a single file. I expect the file to have the
same size and checksum as the one extracted with amfetchdump, which was
readable by tar.
-rw-r--r-- 1 root root 14392979208 2010-10-07 08:24 datastream
subversion:/backup/amanda# md5sum datastream
ff8be5fc30962fceb00025382d819862 datastream
-rw------- 1 amandabackup disk 14392950784 2010-10-06 11:05
subversion.ruf.ch._data.20101002010001.
amandabac...@amanda:/amanda-holding$ md5sum
subversion.ruf.ch._data.20101002010001.0
f016f1ed5c2ee654d825419fde2316b3 subversion.ruf.ch._data.20101002010001.0
OK they are different and I cannot read the datastream which was piped to
tar.
Looking at the difference it appears that the right at the start of the
datastream there is a difference.
This here is ftom the unreadable file
0000000 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0067400 0000 0000 0000 0000 2f2e 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 . / \0 \0 \0 \0 \0 \0
0067420 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0067540 0000 0000 0000 0000 0000 0000 3030 3030
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0 0 0 0
0067560 3737 0037 3030 3030 3030 0030 3030 3030
7 7 7 \0 0 0 0 0 0 0 0 \0 0 0 0 0
0067600 3030 0030 3030 3030 3030 3030 3330 0032
0 0 0 \0 0 0 0 0 0 0 0 0 0 3 2 \0
0067620 3131 3334 3636 3436 3534 0037 3130 3132
1 1 4 3 6 6 6 4 4 5 7 \0 0 1 2 1
0067640 3535 2000 0044 0000 0000 0000 0000 0000
5 5 \0 D \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0067660 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
And this is from the readable file
0000000 2f2e 0000 0000 0000 0000 0000 0000 0000
. / \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000020 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000140 0000 0000 3030 3030 3737 0037 3030 3030
\0 \0 \0 \0 0 0 0 0 7 7 7 \0 0 0 0 0
0000160 3030 0030 3030 3030 3030 0030 3030 3030
0 0 0 \0 0 0 0 0 0 0 0 \0 0 0 0 0
0000200 3030 3030 3330 0032 3131 3334 3636 3436
0 0 0 0 0 3 2 \0 1 1 4 3 6 6 6 4
0000220 3534 0037 3130 3132 3535 2000 0044 0000
4 5 7 \0 0 1 2 1 5 5 \0 D \0 \0 \0
0000240 0000 0000 0000 0000 0000 0000 0000 0000
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
It looks like at offset octal 67410 there is similar data
And indeed at that offset data can be read
subversion:/backup/amanda# dd if=datastream skip=28424 bs=1 | tar tf -
./
./amanda/
./lost+found/
./svn/
./svn/.ssh/
./svn/backup/
./svn/repositories/
./svn/repositories/RT_DevCom/
./svn/repositories/RT_DevCom/conf/
./svn/repositories/RT_DevCom/db/
./svn/repositories/RT_DevCom/db/locks/
./svn/repositories/RT_DevCom/db/locks/090/
./svn/repositories/RT_DevCom/db/locks/104/
./svn/repositories/RT_DevCom/db/locks/151/
./svn/repositories/RT_DevCom/db/locks/60e/
./svn/repositories/RT_DevCom/db/locks/666/
./svn/repositories/RT_DevCom/db/locks/a7e/
./svn/repositories/RT_DevCom/db/locks/b52/
./svn/repositories/RT_DevCom/db/revprops/
./svn/repositories/RT_DevCom/db/revprops/0/
./svn/repositories/RT_DevCom/db/revs/
./svn/repositories/RT_DevCom/db/revs/0/
./svn/repositories/RT_DevCom/db/transactions/
./svn/repositories/RT_DevCom/db/txn-protorevs/
./svn/repositories/RT_DevCom/hooks/
I guess this finding should give you something to chew on
Cheers
Erich
smime.p7s
Description: S/MIME cryptographic signature
