Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <6511FBDA-1F5E-403D-A0BA-C08E7DABCC2D@gmail.com>
References: <AANLkTimcx+YVM3V9yWx3LrkBxoK-OjpkCpcFEz=p=QRv@mail.gmail.com>
 <AANLkTimQLCOR-=+VKEaRn86Zjfm_J3DVWvbAikUBM9Eh@mail.gmail.com>
 <AANLkTim-eGpRF6VSy7mLNZEMLUeN53CmtqRHtG_DSRt3@mail.gmail.com>
 <AANLkTincLdjDtZC8gD4_Xkk0XJNpO5aurnDCLQgc3=ik@mail.gmail.com>
 <1690416A-4C01-4756-9D3B-A256DC729813@apache.org>
 <154AD543-C787-441C-851B-D59CEA6765CC@apache.org>
 <5F47BBB4-9F58-4EFE-92C8-B0FEDA5B01B7@apache.org>
 <AANLkTimK-S_5uoBtq5Dmoy5iuH7RnZXs-XYsnntbDb=P@mail.gmail.com>
 <AANLkTikKEaMi=kdVKPjsqDpvwsMG7L8EvkM7xuNywvrM@mail.gmail.com>
 <12229601-B7B8-4E98-931E-054DA00C5092@apache.org> <20100810130338.GA2584@two>
 <9A625192-F6F5-4AF4-A71E-BE0082789AA5@apache.org>
 <69F9CA20-2EE8-4AA0-9D4B-084EB994D920@apache.org>
 <594EF248-98DE-4F10-9C8F-2083EA2DEBE0@apache.org>
 <AANLkTinDyt=4PT3_DAvraXCJ8+msnQk=bV+6FT7nT1k_@mail.gmail.com>
 <9A34A746-AED9-4FA5-A60E-A40877681C71@apache.org>
 <AANLkTin=vBRNGp1MO5e_4NhMamnML9g9WZX=n-iVCUrO@mail.gmail.com>
 <AANLkTi=4EE+jjo2igrWUuNo4=v3yvNqh_56oN2rFCcW6@mail.gmail.com>
 <AANLkTincX2KTJsGuEWNRXxFc6Ts_di1E_uoRuzu_4X1B@mail.gmail.com>
 <486C68C5-9623-46A2-9681-CBC2BEC56BDA@apache.org>
 <AANLkTimWLY4AV0hL+x9naA-t_bE-0vj8Sq0sb4jhTBxU@mail.gmail.com>
 <AANLkTinRjKc+2EM+SPUq3P8hdyzo7jvmarLH+0SQhw7G@mail.gmail.com>
 <744232E6-D27B-4C7C-9496-7D3F1A8BE8AC@apache.org>
 <6511FBDA-1F5E-403D-A0BA-C08E7DABCC2D@gmail.com>
From: Jason Smith <jhs@couch.io>
Date: Fri, 13 Aug 2010 02:14:35 +0700
Message-ID: <AANLkTi=M10dd17eQ+UTSfHPh880WxS9LgD6633UDFO0r@mail.gmail.com>
Subject: Re: data recovery tool progress
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=00504502c77d87ad8e048da52e11

--00504502c77d87ad8e048da52e11
Content-Type: text/plain; charset=UTF-8

The code is updated with the following changes:
 1. Adhere to the lost+found/databasename custom...
 2. ...except databases starting with _, which goes into
_system/databasename
 3. Sync up with jchris's db_repair branch

(About #2, I started with _/database but I think it's too easy to miss at
the command line.)

On Fri, Aug 13, 2010 at 00:52, J Chris Anderson <jchris@gmail.com> wrote:

> A few bug reports from my testing:
>
> I launched with this command, as specified in the README:
>
> find ~/code/couchdb/tmp/lib -type f -name '*.couch' -exec ./recover_couchdb
> {} \;
>
>
>
> First of all, it chokes on my _users and _replicator db:
>
> [info] [<0.2.0>] couch_db_repair for _users - scanning 335961 bytes at 0
> [error] [<0.2.0>] couch_db_repair merge node at 332061 {case_clause,
>                                      {error,illegal_database_name}}
>
> That second [error] line is repeated many many times (once per merge I
> think). I think the issue is that _users is hard-coded to be OK, but
> _users_lost+found is not. So we should do something about that, maybe if a
> db-name starts with _ we should call the lost and found a_users_lost+found
> (_ sorts at the top, so "a" will be near it and legal).
>
>
>
> When a database has readers defined in the security object, the tool is
> unable to open them (the reading part of the repair tool needs to have the
> _admin userCtx, not just the writer).
>
> [debug] [<0.2.0>] Not a reader: UserCtx {user_ctx,null,[],undefined} vs
> Names [<<"joe">>] Roles [<<"_admin">>]
> escript: exception throw: {unauthorized,<<"You are not authorized to access
> this db.">>}
>  in function  couch_db:open/2
>  in call from couch_db_repair:make_lost_and_found/3
>  in call from recover_couchdb:main/1
>  in call from escript:run/2
>  in call from escript:start/1
>  in call from init:start_it/1
>  in call from init:start_em/1
>
>
> It would also be helpful if the status lines could say something more than
>
> [info] [<0.2.0>] couch_db_repair writing 15 updates to bench_lost+found
>
> Like maybe add a note like "about 23% complete" if at all possible.
>
>
> I will patch the first few, I'd love help from someone on the last one.
> I'll be on IRC.
>
>
> Cheers,
> Chris
>
>
>
>
>
>
>
> On Aug 12, 2010, at 10:18 AM, J Chris Anderson wrote:
>
> >
> > On Aug 11, 2010, at 2:14 PM, Jason Smith wrote:
> >
> >> Hi, Jason.
> >>
> >> On Thu, Aug 12, 2010 at 04:14, Jason Smith <jhs@couch.io> wrote:
> >>
> >>> On Wed, Aug 11, 2010 at 09:52, Adam Kocoloski <kocolosk@apache.org>
> wrote:
> >>>
> >>>> Excellent, thanks for testing.  I caught Jason Smith saying on IRC
> that he
> >>>> had packaged the whole thing up as an escript + some .beams.  If we
> can get
> >>>> it down to a single file a la rebar that would be a pretty sweet way
> to
> >>>> deliver the repair tool in my opinion.
> >>>>
> >>>
> >>> Please check out http://github.com/jhs/repair-couchdb
> >>>
> >>
> >> I think you mean http://github.com/jhs/recover-couchdb
> >>
> >
> > I think it is important that we package and release this, if it is ready.
> We should link to it from the bug description page, the project home page,
> as well as blog about it, etc. What is the point of working feverishly on a
> recovery tool if we don't go the last mile?
> >
> > I am testing it now on my database directory to make sure it doesn't harm
> anything (I was never subject to the bug, which is probably where most
> people are, but they might run it anyway.)
> >
> > As it stands the submodules thing can't be part of the release, we need
> to package it up as a single zip file or something.
> >
> > Is there anything else that needs to be done before we can release this?
> >
> > Chris
> >
> >> --
> >> Jason Smith
> >> Couchio Hosting
> >
>
>


-- 
Jason Smith
Couchio Hosting

--00504502c77d87ad8e048da52e11--