Re: [Monotone-devel] Violated invariants, nasty server keys, ignored hooks

[Nathaniel Smith]

On Wed, Apr 27, 2005 at 03:35:30PM +1200, Oleg Polianski wrote:
> Hi there,
> 
>  I have been pondering what I could have done wrong contemplating
>  on these two use cases.
> 
>  1. I had a monotone 0.17 database created earlier on, which I have
>     recently migrated on to the 0.18 format. Since that happened,
>     I can't perform any file related operations anymore (add and drop
>     in particular), `monotone' informs me of a violated invariant:
> 
> % monotone --db=../rmsgd.db.backup add README
> monotone: fatal: std::logic_error: path_component.cc:53: invariant 
> 'I(!null_name(*i))' violated
> 
>     When I look into the MT/debug file, I can't find anything useful
>     that would give me a clue or a hint of direction to look in,
>     with the last several lines reporting
> 
> db.fetch("SELECT data FROM 'manifests' WHERE id = 
> '439ddc4b78e2e8e858f29f2005293833c695440e'")
> old manifest has 63 entries
> work path is MT/work
> checking for un-committed work file MT/work
> read rearrangement from MT/work
> 'README' prefixed to 'README'
> path_component.cc:53: invariant 'I(!null_name(*i))' violated
> 
>     The problem is persistent all the way down the project tree.
>     Any real reason for that?

Hard to say from just this description.  I would guess that your
MT/work file has something invalid in it; would it be possible to post
it?

>  2. To work the first problem around, I decided to afford the luxury
>     of recreating the monotone database from scratch and do a fresh
>     import of my source code on host X. Having done that, I went on
>     to host Y, where I created another empty monotone database and
>     attempted to do a full sync (X->Y). One of my intentions was for
>     all previously generated and used private and public keys to
>     stay the same, so after I had recreated each database, I had
>     also extracted the keys from a backup copy of each one and then
>     reloaded them (via `monotone read') into each database accordingly.
>     Now, when I try to sync the Y database with the X database,
>     `monotone' on the receiving side, among the lines, spits out
> 
> monotone: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> monotone: @ WARNING: SERVER IDENTIFICATION HAS CHANGED              @
> monotone: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> monotone: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY
> monotone: it is also possible that the server key has just been changed
> monotone: remote host sent key 88de5cc64a05fe7f3d17522e675cef860cce2ef7
> monotone: I expected 549c2e9f3556ee5ba39f6bc00e8aa25d0f15a8c5
> 
>     The thing is that I don't have such a server key or anything
>     that closely resembles the 549c2e9f3556ee5ba39f6bc00e8aa25d0f15a8c5
>     fingerprint neither on the serving side nor on the sending
>     side. This has left confused even more.

Again, hard to say.  You presumably did have such a key at some point
(maybe while testing or something?), since monotone got it from
somewhere :-).  In any case, if you follow the directions the message
gives ('monotone unset known-servers <hostname>'), it will tell
monotone to go ahead anyway.

>  There is actually a third slight problem, which stems from the
>  collection of several different things, I guess, mostly related to
>  fiddling with the private and public keys via the means of
>  `monotone pubkey/privkey' and the subsequent `monotone read' and
>  expresses itself as ignoring the `get_passphrase' hook in my
>  `~/.monotonerc' file that worked before just beatifully.

Strange; I haven't heard of a problem like this before.  Try running a
command that requires your passphrase with --debug, and see if that
tells you anything useful?  (Or mail to the list, if it's not too
long... the debug log for a full netsync, for instance, might be too
long, so don't do that :-).)

>  I still have a glimmer of hope that I would not have to go through
>  all of this each time I upgrade the monotone binary and I would
>  appreciate any help in dealing with these peculiarities of the
>  monotone's behaviour. Additional information can be easily
>  provided, should that be required.

I'm sorry it's caused so many problems for you.  I haven't heard of
other people encountering problems like any of these, so I _suspect_
it's some unfotunate quirks of your configuration, but it would be
good to get more information to get to the bottom of it.

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender