Re: Wish: -r option to recover a crashed session
Hi,
I like Cameron's idea about the "sync--and-quit-on-HUP-or-TERM" option.
The problem I'm trying to workaround is when my VPN hiccups, or when DSL
hiccups; also, I log into my Unix system (at work) via Exceed on my PC
(when working from home, that is). So if Cameron's suggestion could in
fact sync up my mailbox before it exited, that would be great. I also
like the idea of postponing any message that is being composed at the
time of the hiccup.
Would it be possible to mark the message mutt was on when it terminated
via an X-Label or something?
--
Mun
On Sat, Jul 10, 2004 at 05:04 AM PDT, Cameron Simpson wrote:
CS> On 01:21 09 Jul 2004, Gary Johnson <garyjohn@xxxxxxxxxxxxxxx> wrote:
CS> | On 2004-07-09, Cameron Simpson <cs@xxxxxxxxxx> wrote:
CS> | > On 21:59 05 Jul 2004, Gary Johnson <garyjohn@xxxxxxxxxxxxxxx> wrote:
CS> | > | On 2004-07-05, "Roy S. Rapoport" <mutt-users@xxxxxxxxxxxxxxxxx> wrote:
CS> | > | > Dude, Mun Johl seems to specifically address _mutt_ dying.
CS> | > | In his original posting he began,
CS> | > | There are times when I'm going through my mbox and I have
CS> | > | deleted items, applied labels, etc. and before I sync up the
CS> | > | file I loose my network connection for some reason.
CS> | > |
CS> | > | So while he was asking for a solution to the general problem of mutt
CS> | > | dying, his specific problem seemed to be that his network connection
CS> | > | was dropping.
CS> | >
CS> | > Then he's probably getting a SIGHUP as his terminal hangs up.
CS> | >
CS> | > Sounds like one route would be to give mutt a
"sync--and-quit-on-HUP-or-TERM"
CS> | > switch, defaulting to on. Thoughts?
CS> |
CS> | That would update the state of the current folder before mutt
CS> | stopped, but it wouldn't save anything else about the state of mutt
CS> | before it stopped, which may or may not be OK.
CS>
CS> It's enough for his description above, but you have a point.
CS> Still, it would go a long way to addressing his issue.
CS>
CS> | If the user was in
CS> | the compose menu, for example, nothing about the message being
CS> | composed would be saved. I'm not sure what would happen if the user
CS> | was editing a message when SIGHUP was generated.
CS> |
CS> | So my thought is that a "sync--and-quit-on-HUP-or-TERM" switch
CS> | wouldn't be enough to avoid frustrating data loss upon an unexpected
CS> | hang-up.
CS>
CS> Well I see two approaches to this, one already ok.
CS>
CS> Firstly, editors tend to save interrupted sessions. So that's so of ok.
CS>
CS> Second, when I abort a mutt compose session it asks if I want the message
CS> postponed. Have any message in compose mode _be_ in the postponed queue,
CS> and have that question undo that state if necessary. In this way the
CS> compose state is covered too.
CS>
CS> Sound ok?
CS> --
CS> Cameron Simpson <cs@xxxxxxxxxx> DoD#743
CS> http://www.cskk.ezoshosting.com/cs/