Re: [Mailsync-list] mh sync

[Tomas P. <tp...@so...>]

On Thu, 10 Jun 2004, Michael 'hacker' Krelin wrote:

> > > > Yet another attempt on fix. Once again after such a long break in
> > > > digging mailsync I'm totally lost in all the mailbox open operations,
> > > > but this is what I had to do without using if(ismh) to get mh sync
> > > > properly. basically, mailbox_open makes mh mailboxes forget about
> > > > messages flagged for removal.
> > >
> > > Strange, this should be fixed in the c-client code.
>
> I don't think it will be fixed, though...

I think someone has to send a patch. And it will be applied then. I
guess, why shouldn't it? Do you have some example that it wouldn't? Do
you think it won't? Why?

> > > > So, I had to expunge mail before going any
> > > > further and not open it if it's already open. I have no clue if it will
> > > > break anything or not...
> > >
> > > I spend quite some time pondering this and going through all the
> > > mail_open's. And I think it will not break anything... I've committed a
> > > slightly modified version - thanks *a lot*!!!
> >
> > OK, no, actually it can't work. The problem is seen below:
> >
> > Synchronizing stores "local-inbox" <-> "remote-inbox"...
> > Authorizing against {[192.168.1.2]/imap}
> >
> >  *** INBOX ***
> >
> >   deleted    >   Mon Jun  7 Some One           RE : Re: [Afbackup-devel] Re:
> >   deleted    >   Sun Jun  6 Some Other         mailsync; ssh vs rsh
> >   deleted    >   Sat Jun  5 A Person
> >   deleted    >   Mon Jun  7 Another P          Vorstudie
> > Expunged 4 mails in store eis-inbox
> > Authorizing against {[192.168.1.2]/imap}
> > Error: Bad msgno 67 in mail_elt, nmsgs = 64
> > A fatal error occured - terminating
> > Aborted
> >
> > What we did here is expunge messages and then try to copy other messages
> > back and forth. The problem is, that the numbering has changed because of
> > expunging some emails inbetween.
>
> Yes.. We've had this problem before...
>
> > I'll have to reverse your patch. It seems that c-client needs to be fixed
> > (see osdep/mh.c -> mh_check for reference) in order to not loose
> > information on what messages have been deleted when reopening a
> > connection.
> >
> > Talking of which and for reference - how do messages scheduled for removal
> > look like in mh? Are they moved somewhere? Or is their filename changed?
> > Or is a flag set within the message?
>
> I'm afraid c-client only keeps this information in memory. When one
> expunges message it simply unlinks files. MH itself renames files
> prepending them with ',' instead of unlinking.

Ah, OK, I've found an online MH reference [1], so removing a message means
adding a ',' or a '#' in front of it [2].

So what would be needed for the c-client mh driver to work properly
(within our scope) is to rename all files that were marked as deleted in
the mh_check function.

Michael ;-) ?

> Is there any way to avoid reopening mailbox? Of course one can also
> reread msgids after expunging, but it's a waste of time and bandwidth in
> case of non-nmh mailbox...

The problem is that we are trying to only "HALFOPEN" the store and open a
mailbox we read from READONLY so that the messages don't get altered (that
means status set to "Seen" (here Status: O (as in "old"))), because some
MUA rely on it.

In mutt a message is only new if it has the "N" flag set (which I don't
know how to accomplish through c-client) or has *not* the "O" flag set.

That means if we mess up the flags, then mutt users won't see new
messages. Unfortunately that doesn't seem to work either these days... :-(

There is also the OP_EXPUNGE flag for opening in c-client. We could try to
use it. The problem is, that it will expunge messages only when changing
the "stream", which means switching to a different mailbox. That means
we'd need to change the structure of the program a bit (mailsync_main) to
tell the user about expunging emails *at the beginning* of the loop when
switching to the next box to be synched...

Alternatively you had some "if #mh" hacks. I'll check those out.
*t

[1] http://www.ics.uci.edu/~mh/book/mh/tocs/jump.htm
[2] http://www.ics.uci.edu/~mh/book/mh/rem.htm

--
--------------------------------------------------------
  Tomas Pospisek
  http://sourcepole.com -  Linux & Open Source Solutions
--------------------------------------------------------