Re: [Mailsync-list] mh sync

[Michael 'h. K. <mai...@zz...>]

> > > > > 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?

No, I didn't mean to bash MC for unwilling to cooperate (although, I
think he's quite conservative, since neither older imap, nor imap2004
doesn't compile will even with gcc3.0). It's just that I don't feel like
fixing it and I don't think that many people use mh nowadays.

On the other hand, even if it gets fixed, I think we need a workaround
for current version...

> > 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 ;-) ?

The problem is, that messages with , or # in front of it are _removed_
from mh's point of view, not flagged for removal. So, this is not
exactly what we need here.

> > 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... :-(

I use `mark +inbox all -sequence beforesync' before mailsyncing and `mark
+inbox notbeforesync -add -sequence unseen` after.

Which gives an idea of adding a sequence for flagged messages... But
then again... I think mailsync should be capable of working with current
cclient too...

> 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.

It looks like it's the only way, although, I agree that there's no
beauty in it. BTW, if syncing with proper flags doesn't work, anyway,
why not just do it as if we're always if(mh)?

Love,
H