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 <jch...@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 <j...@couch.io> wrote: > >> > >>> On Wed, Aug 11, 2010 at 09:52, Adam Kocoloski <kocol...@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