[9fans] P9P venti/copy bug?

[9fans] P9P venti/copy bug?

[Venkatesh Srinivas]

Hi,

When I use venti/copy from plan 9 port to try to copy certain archives between
two venti servers, I get the following error:

vcopy: reading block 0000000000000000000000000000000000000000 (type 16): read
asked for 0000000000000000000000000000000000000000 got
da39a3ee5e6b4b0d3255bfef95601890afd80709

da39.. is the sha1sum of the empty string, which is suspicious.

Plan 9's venti/copy is able to copy this archive just fine.

An example failing vac archive:

tcp!acm.jhu.edu!17001   vac:a909a0eb1f0b3e7bb7248e4eaeadfc4cf06aa346

Has anyone else run into this problem?

-- vs

Re: [9fans] P9P venti/copy bug?

[Russ Cox]

On Mon, Feb 9, 2009 at 4:56 AM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
> vcopy: reading block 0000000000000000000000000000000000000000 (type 16):
> read asked for 0000000000000000000000000000000000000000 got
> da39a3ee5e6b4b0d3255bfef95601890afd80709

The real question is how you got an archive with an all zeros score in it.
There are some programs that use that internally to mean "no block"
but any time such a block is written to venti, the score should be the
zero-byte sha1 da39...0709.

Russ

Re: [9fans] P9P venti/copy bug?

[Venkatesh Srinivas]

On Mon, Feb 09, 2009 at 08:48:33AM -0800, Russ Cox wrote:
>On Mon, Feb 9, 2009 at 4:56 AM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
>> vcopy: reading block 0000000000000000000000000000000000000000 (type 16):
>> read asked for 0000000000000000000000000000000000000000 got
>> da39a3ee5e6b4b0d3255bfef95601890afd80709
>
>The real question is how you got an archive with an all zeros score in it.
>There are some programs that use that internally to mean "no block"
>but any time such a block is written to venti, the score should be the
>zero-byte sha1 da39...0709.
>

When I use -V with Plan 9's vcopy, the zero score block isn't listed...
I suspect that the block with the zero score is not actually in the archive?

-- vs

Re: [9fans] P9P venti/copy bug?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On Mon, Feb 09, 2009 at 11:55:05AM -0500, Venkatesh Srinivas wrote:
> On Mon, Feb 09, 2009 at 08:48:33AM -0800, Russ Cox wrote:
>> On Mon, Feb 9, 2009 at 4:56 AM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
>>> vcopy: reading block 0000000000000000000000000000000000000000 (type 16):
>>> read asked for 0000000000000000000000000000000000000000 got
>>> da39a3ee5e6b4b0d3255bfef95601890afd80709
>>
>> The real question is how you got an archive with an all zeros score in it.
>> There are some programs that use that internally to mean "no block"
>> but any time such a block is written to venti, the score should be the
>> zero-byte sha1 da39...0709.
>>
>
> When I use -V with Plan 9's vcopy, the zero score block isn't listed...  
> I suspect that the block with the zero score is not actually in the 
> archive?
>
> -- vs
>

I just tripped over this myself and found that apparently Plan 9 native vac
sets root.prev to all zeros when there is no previous root.  So I applied
the diff below.  I'm not sure this is a correct fix?

--nwf;

diff -r 74392a7c323c src/cmd/venti/copy.c
--- a/src/cmd/venti/copy.c      Wed Mar 11 13:37:29 2009 -0700
+++ b/src/cmd/venti/copy.c      Tue Mar 31 03:12:53 2009 -0400
@@ -10,6 +10,8 @@
 int fast;
 int verbose;
 VtConn *zsrc, *zdst;
+
+uchar allzeros[VtScoreSize];
 
 void
 usage(void)
@@ -54,7 +56,8 @@
			break;
		}
		walk(root.score, VtDirType, 0);
-   walk(root.prev, VtRootType, 0);
+   if(memcmp(root.prev, allzeros, VtScoreSize))
+     walk(root.prev, VtRootType, 0);
		if(rewrite)
			vtrootpack(&root, buf); /* walk might have changed score */
		break;


[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]