Subject: [sup-talk] ~/.sup/sources.yaml disappearing

From: [email-masked] (jeff covey)
Date: Sun, 10 Jun 2007 14:00:44 -0400

has anyone else experienced a problem with ~/.sup/sources.yaml being wiped
out?  it's gone away on me a few times, though i'm not sure exactly what
happens to it.  sup hits an error, and either deletes sources.yaml or makes
it an empty file.  i can't say which, i just suddenly notice that my sup
wrapper script is running sup-add to add a bunch of sources which should
already be there, and when i look at sources.yaml, it's starting to rebuild
my supiverse from scratch.

i'm afraid i can't say what caused it, either.  the latest time it happened
was with an error about draw_screen, but the backtrace was gone too fast for
me to grab it.

sorry to give you so little information, william.  maybe you could check the
handling of sources.yaml generally?  maybe there's a place where it's opened
for writing, then never closed before an error occurs?

i'll try to get more details if it happens again.

thanks,

-- 
jeff covey
http://jeffcovey.net/

---

From: [email-masked] (jeff covey)
Date: Sun, 10 Jun 2007 17:57:11 -0400

ok, it happened again[0] and i was able to catch it this time.

i hit "q" to quit sup while it was in the middle of doing something (polling
for new messages, i believe), and got this:

[Sun Jun 10 16:07:48 -0400 2007] good night, sweet prince!
[Sun Jun 10 16:07:48 -0400 2007] saving index and sources...
./lib/sup/util.rb:313:in `send': undefined method `draw_screen' for nil:NilClass (NoMethodError)
        from ./lib/sup/util.rb:313:in `method_missing'
        from ./lib/sup/modes/poll-mode.rb:12:in `puts'
        from ./lib/sup/modes/poll-mode.rb:20:in `poll'
        from ./lib/sup/poll.rb:59:in `do_poll'
        from ./lib/sup/poll.rb:115:in `add_messages_from'
        from ./lib/sup/source.rb:91:in `each'
        from ./lib/sup/util.rb:349:in `send'
        from ./lib/sup/util.rb:349:in `__pass'
         ... 26 levels...
        from ./lib/sup.rb:56:in `reporting_thread'
        from ./lib/sup/modes/thread-index-mode.rb:342:in `load_n_threads_background'
        from ./lib/sup/modes/thread-index-mode.rb:391:in `load_threads'
        from bin/sup:171

after that, my sources.yaml was reset to nothing, and all the associated
problems followed as before.

thanks,
jeff

[0] and i had to rebuild my whole sup setup from scratch again.  :(

-- 
jeff covey
http://jeffcovey.net/

---

From: [email-masked] (William Morgan)
Date: Mon, 11 Jun 2007 08:42:42 -0700

Hi Jeff,

First let me say that I really appreciate all the feedback and I'm sorry
that Sup keeps breaking in annoying ways for you. Thanks for being
patient. Users like you are an asset!

Excerpts from jeff.covey's message of Sun Jun 10 14:57:11 -0700 2007:
> i hit "q" to quit sup while it was in the middle of doing something
> (polling for new messages, i believe), and got this:
> 

Ok, here's my first problem. :)

> problems followed as before.

I believe this happens when Sup dies in the process of "saving index and
sources...". The right answer is to remove all possible the sources of
error in that process, but maybe I can also change the code to be a
little more resilient. Let me take a look.

> [0] and i had to rebuild my whole sup setup from scratch again.  :(

Sup writes a sources.yaml.bak for this very reason. I put it in in
earlier, even buggier days when this often happened to me.

-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (William Morgan)
Date: Tue, 12 Jun 2007 17:48:50 -0700

> Ok, here's my first problem. :)

This particular problem should now be fixed, and similar problems mitigated.

> I believe this happens when Sup dies in the process of "saving index
> and sources...". The right answer is to remove all possible the
> sources of error in that process, but maybe I can also change the code
> to be a little more resilient. Let me take a look.

I'm still not sure why sources.yaml, of all files, would end up being
zero, since the write was pretty atomic, but I've now made it even more
atomic, so hopefully this shouldn't happen too often any more.