Changes between Initial Version and Version 1 of Ticket #88


Ignore:
Timestamp:
2007-07-14T05:49:36Z (17 years ago)
Author:
warner
Comment:

the exception is marked as a LOCAL foolscap one, but the other three nodes don't have a corresponding REMOTE exception in their logs. It's possible that there's a fourth node out there that's connecting and trying to find its long-lost private dirnode, but the storage index keeps changing, and it seems to happen right at the beginning of a large directory upload.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #88

    • Property Status changed from new to assigned

  • Ticket #88 – Description

    initial v1  
    11I'm not sure why, but uploading a directory (the tahoe source tree), using 'curl', causes a (benign) exception in the vdrive server:
    2         LOCAL:   File "/home/amduser/trunk/instdir/lib/allmydata/dirnode.py", line 81, in get
    3         LOCAL:     raise KeyError("unable to find key %s" % idlib.b2a(key))
    4         LOCAL: exceptions.KeyError: 'unable to find key uumzl6h4bokrkamr2z742hexgyg6oin2elowlkdrhfpd5hair3ya===='
     2
     3{{{
     4LOCAL:   File "/home/amduser/trunk/instdir/lib/allmydata/dirnode.py", line 81, in get
     5LOCAL:     raise KeyError("unable to find key %s" % idlib.b2a(key))
     6LOCAL: exceptions.KeyError: 'unable to find key uumzl6h4bokrkamr2z742hexgyg6oin2elowlkdrhfpd5hair3ya===='
     7}}}
    58
    69I suspect that part of the upload process creates an empty directory and then tries to use it before the operation has completed, or something. I need to poke through the existing dirnodes and find which one references this one.