mailsync-list — discussion about development, config, bugs etc.

Re: [Mailsync-list] Re: Bug/Feature requests for mailsync

[Christian S. <Chr...@gm...>]

Michael 'hacker' Krelin wrote:
> A long before I ever looked up the code of mailsync I got a feeling that
> one can use \ to escape characters (I had to use it to allow synchronize
> #mh/ mailboxen). I believe that should do for spaces as well (Haven't
> checked the code or tested, though).

Ohh, shame on me! In the machine where I wrote the scripts there is
mailsync 4.5.3 installed. There is no escape example in
examples/mailsync.gz but in the file of the new version is. I didn't see
this, sorry.=20

regards,
Christian

Re: [Mailsync-list] Re: Bug/Feature requests for mailsync

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

On Fri, Jul 09, 2004 at 05:11:28PM +0200, Tomas Pospisek wrote:
> Ciao
> 
> Please use the mailsync list [1] for communication about mailsync. But see
> below...
> 
> On Fri, 9 Jul 2004, Christian Schrader wrote:
> 
> > while migrating a mailserver I found two Bugs/missing features:
> >
> > 1. It is not possible to specify mailboxes with spaces in the name
> >    for pat in the config file. I tweaked the config parser that I can
> >    use quotes. Well, I cannot program so this is just a hack to get my
> >    work done.

A long before I ever looked up the code of mailsync I got a feeling that
one can use \ to escape characters (I had to use it to allow synchronize
#mh/ mailboxen). I believe that should do for spaces as well (Haven't
checked the code or tested, though).

Of course it doesn't mean that quoting should not be allowed as well.

> > 2. It should be possible to disable the use of SSL via commandline
> >    switch or config option. Now it is only possible to enable it.
> >    The mailsync on Debian/Sarge tried to use SSL per default and I got
> >    an SSL-Error with an old uw-imapd on the other side. I had to rebuild
> >    libc-client and mailsync without SSL support.
> 
> What about /notls or /nossl? Doesn't that work?

I remember I had problems with disabling SSL (don't remember what the
problem was -- I think it insised on SSL if there was a listener set up
on remote host on the SSL port, but it is weird if it is so). I'd blame
it on c-client, anyway...

Love,
H

[Mailsync-list] Re: Bug/Feature requests for mailsync

[Christian S. <Chr...@gm...>]

Hi,

Tomas Pospisek wrote:
> Please use the mailsync list [1] for communication about mailsync. But
> see below...

ok

> OK, I'll have a look at it, but not before after holidays (...august).

No need to hurry. I got my work done. :)

> What about /notls or /nossl? Doesn't that work?
> *t

I greped the doku for "ssl" and did not found /nossl but i I tried it to
see if this works. It didnt. The /notls I didn't see and didn't try.

regards,
Christian

[Mailsync-list] Re: Bug/Feature requests for mailsync

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

Ciao

Please use the mailsync list [1] for communication about mailsync. But see
below...

On Fri, 9 Jul 2004, Christian Schrader wrote:

> while migrating a mailserver I found two Bugs/missing features:
>
> 1. It is not possible to specify mailboxes with spaces in the name
>    for pat in the config file. I tweaked the config parser that I can
>    use quotes. Well, I cannot program so this is just a hack to get my
>    work done.
>
> (patch against mailsync-5.2.1)
> ------------------------ snip ----------------------------
> --- configuration.cc.orig       2004-06-14 13:34:04.000000000 +0200
> +++ configuration.cc    2004-07-09 11:00:18.000000000 +0200
> @@ -66,6 +66,7 @@
>  //////////////////////////////////////////////////////////////////////////
>  {
>    int c;
> +  int inq = 0;
>    t->buf = "";
>    t->eof = 0;
>    while (1) {
> @@ -93,7 +94,10 @@
>
>      // We've reached a token boundary
>      }
> -    else if (isspace(c)) {
> +    else if (c=='"') {
> +      inq = !inq;
> +    }
> +    else if (isspace(c)  && !inq) {
>        // The token is non empty so we've acquired something and can
>        // return
>        if (t->buf.size()) {
>          break;
> ------------------------ snip ----------------------------

OK, I'll have a look at it, but not before after holidays (...august).

> 2. It should be possible to disable the use of SSL via commandline
>    switch or config option. Now it is only possible to enable it.
>    The mailsync on Debian/Sarge tried to use SSL per default and I got
>    an SSL-Error with an old uw-imapd on the other side. I had to rebuild
>    libc-client and mailsync without SSL support.

What about /notls or /nossl? Doesn't that work?
*t

[1] http://sourceforge.net/mail/?group_id=6374

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

Re: [Mailsync-list] mailsync asking for password repeatedly

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

> > As for the bug, just in case I'm one of those who are expected to look
> > at it -- I have no idea... Could it be related to those
> > opening/reopening mailboxes changes that has happened lately?
> 
> I do think so. I haven't looked at the code, but in case we do a close
> somewhere inbetween than similar things /could/ happen.

I'll try to find some time and take a look (no promises, though,
regarding timeframes).

Love,
H

Re: [Mailsync-list] mailsync asking for password repeatedly

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

On Sun, 4 Jul 2004, Michael 'hacker' Krelin wrote:

> On Sun, Jul 04, 2004 at 04:47:36PM -0400, Eric S. Johansson wrote:
> > Tomas Pospisek wrote:
> >
> > >PS: Eric, I know, I haven't resolved your problem yet. I hope you've been
> > >    able to terminate the project nevertheless :-/
> >
> > people have moved over to the server.  They're mostly happy with a new
> > speed and I just need to update to the latest camram and the anti-spam
> > world will be happier for them.
> >
> > Solution was to rsync old mailboxes to new machine.  on moving day, I did
> > one final synchronization and then converted all of the mbx files to mbox
> > then ran mb2md converting everyone to maildir.  <whew>.
> >
> > they were a few burps but for the most part, it worked.
>
> To be true, I think this is more sensible solution than mailsyncing.
> Mailsync is much more usable for everyday syncing...
>
> Speaking of which, the latest CVS still works and gives no unpleasant
> surprises (for me at least). Is it released, yet?

Yes.

> As for the bug, just in case I'm one of those who are expected to look
> at it -- I have no idea... Could it be related to those
> opening/reopening mailboxes changes that has happened lately?

I do think so. I haven't looked at the code, but in case we do a close
somewhere inbetween than similar things /could/ happen.
*t

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

Re: [Mailsync-list] mailsync asking for password repeatedly

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

On Sun, Jul 04, 2004 at 04:47:36PM -0400, Eric S. Johansson wrote:
> Tomas Pospisek wrote:
> 
> >PS: Eric, I know, I haven't resolved your problem yet. I hope you've been
> >    able to terminate the project nevertheless :-/
> 
> people have moved over to the server.  They're mostly happy with a new 
> speed and I just need to update to the latest camram and the anti-spam 
> world will be happier for them.
> 
> Solution was to rsync old mailboxes to new machine.  on moving day, I did 
> one final synchronization and then converted all of the mbx files to mbox 
> then ran mb2md converting everyone to maildir.  <whew>.
> 
> they were a few burps but for the most part, it worked.

To be true, I think this is more sensible solution than mailsyncing.
Mailsync is much more usable for everyday syncing...

Speaking of which, the latest CVS still works and gives no unpleasant
surprises (for me at least). Is it released, yet?

As for the bug, just in case I'm one of those who are expected to look
at it -- I have no idea... Could it be related to those
opening/reopening mailboxes changes that has happened lately?

Love,
H

Re: [Mailsync-list] mailsync asking for password repeatedly

[Eric S. J. <es...@ha...>]

Tomas Pospisek wrote:

> PS: Eric, I know, I haven't resolved your problem yet. I hope you've been
>     able to terminate the project nevertheless :-/

people have moved over to the server.  They're mostly happy with a new speed and I just need to update to the latest camram and the anti-spam world will be happier for them.

Solution was to rsync old mailboxes to new machine.  on moving day, I did one final synchronization and then converted all of the mbx files to mbox then ran mb2md converting everyone to maildir.  <whew>.

they were a few burps but for the most part, it worked.

---eric

[Mailsync-list] mailsync asking for password repeatedly

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

I've got a bugreport here [1] where mailsync keeps on asking for the
password for every mailbox. I probably won't have the time to fix this
before holidays [10.6-10.7]. My hypothesis is, that den connection is
being closed when a mailbox is finished. If anybody wants to have a look
at it, please do so.
*t

[1] bugs.debian.org/257418

PS: Eric, I know, I haven't resolved your problem yet. I hope you've been
    able to terminate the project nevertheless :-/

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

[Mailsync-list] T0p Quality S0ftware at the L0west Possible Priice from Church's S0ftSh0p

[Brandi G. <ton...@ma...>]

In order for the light to shine so brightly, the darkness must be present.
All animals, except man, know that the principal business of life is to enjoy it.
No heroine can create a hero through love of one, but she can give birth to one.
Cure the disease and kill the patient.
Acquaintance. A person whom we know well enough to borrow from, but not well enough to lend to.
It will never rain roses: when we want to have more roses we must plant more trees.
A person will be called to account on Judgment Day for every permissible thing he might have enjoyed but did not.
America is not a blanket woven from one thread, one color, one cloth.
A good many dramatic situations begin with screaming.
Your actions, and your action alone, determines your worth.
It is easy to dodge our responsibilities, but we cannot dodge the consequences of dodging our responsibilities.
The gods sell to us all the goods which they give us.
Abundance is not something we acquire. It is something we tune into.
The only cure for contempt is counter-contempt.

Re: [Mailsync-list] new CVS snapshot

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

On Mon, Jun 14, 2004 at 01:55:59PM +0200, Tomas Pospisek wrote:
> On Mon, 14 Jun 2004, Michael 'hacker' Krelin wrote:
> 
> > And, since the part of the fix made it into the CVS, maybe you will want
> > to patch the rest:
> >
> > Maybe it's better to move #include <c-client.h> to a separate header...
> 
> That's what I did. Thanks for the idea. Committed.

It's been a while since I've had a usable mailsync with empty `cvs
update` output ;-)

Love,
H

Re: [Mailsync-list] new CVS snapshot

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

On Mon, 14 Jun 2004, Michael 'hacker' Krelin wrote:

> And, since the part of the fix made it into the CVS, maybe you will want
> to patch the rest:
>
> Maybe it's better to move #include <c-client.h> to a separate header...

That's what I did. Thanks for the idea. Committed.
*t

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

Re: [Mailsync-list] new CVS snapshot

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

On Mon, Jun 14, 2004 at 11:23:55AM +0200, Tomas Pospisek wrote:
> Hello everybody,
> 
> I've released a new CVS snapshot, which should fix both mh (tested a
> bit) and mutt (messages are not shown as new - tested a bit) problems.
> 
> Please test. This is a release candidate (knocking on wood like a
> woodpecker).
> 
> Thanks a greets for all the bugreporters and all those that are keeping on
> bugging me about their pet mh store not working ;-)

So far so good. Thanks. Will report more if problems arise. I liked the
idea of the fix ;-)

And, since the part of the fix made it into the CVS, maybe you will want
to patch the rest:

Maybe it's better to move #include <c-client.h> to a separate header...

Love,
H

Index: src/c-client_callbacks.cc
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/c-client_callbacks.cc,v
retrieving revision 1.2
diff -u -r1.2 c-client_callbacks.cc
--- src/c-client_callbacks.cc	20 Apr 2003 09:52:00 -0000	1.2
+++ src/c-client_callbacks.cc	14 Jun 2004 11:08:40 -0000
@@ -14,6 +14,8 @@
 
 #include <stdio.h>      // required by c-client.h
 #include <c-client.h>
+#undef max
+#undef min
 
 #include "options.h"
 #include "types.h"
Index: src/channel.cc
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/channel.cc,v
retrieving revision 1.13
diff -u -r1.13 channel.cc
--- src/channel.cc	13 Jun 2004 20:55:04 -0000	1.13
+++ src/channel.cc	14 Jun 2004 11:08:41 -0000
@@ -4,6 +4,8 @@
 #include "types.h"
 #include "mail_handling.h"
 #include <c-client.h>
+#undef max
+#undef min
 #include "msgstring.h"
 #include <flstring.h>
 #include "msgid.h"
Index: src/configuration.cc
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/configuration.cc,v
retrieving revision 1.4
diff -u -r1.4 configuration.cc
--- src/configuration.cc	22 Apr 2003 13:23:08 -0000	1.4
+++ src/configuration.cc	14 Jun 2004 11:08:41 -0000
@@ -4,6 +4,8 @@
 #include <string>
 #include <sys/stat.h>           // Stat()
 #include "c-client.h"           // for MAILTMPLEN
+#undef max
+#undef min
 #include "configuration.h"
 #include "options.h"
 #include "store.h"
Index: src/mail_handling.cc
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/mail_handling.cc,v
retrieving revision 1.4
diff -u -r1.4 mail_handling.cc
--- src/mail_handling.cc	27 Mar 2003 18:11:34 -0000	1.4
+++ src/mail_handling.cc	14 Jun 2004 11:08:41 -0000
@@ -1,6 +1,8 @@
 #include <stdio.h>  // required by c-client.h
 #include <ctype.h>
 #include "c-client.h"
+#undef max
+#undef min
 #include "options.h"
 #include "types.h"
 #include "msgstring.h"
Index: src/mail_handling.h
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/mail_handling.h,v
retrieving revision 1.2
diff -u -r1.2 mail_handling.h
--- src/mail_handling.h	23 Mar 2003 21:06:45 -0000	1.2
+++ src/mail_handling.h	14 Jun 2004 11:08:41 -0000
@@ -1,5 +1,7 @@
 #ifndef __MAILSYNC_MAILHANDLING__
 #include "c-client.h"
+#undef max
+#undef min
 
 //------------------------- Helper functions -----------------------------
 
Index: src/msgid.cc
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/msgid.cc,v
retrieving revision 1.8
diff -u -r1.8 msgid.cc
--- src/msgid.cc	2 Jun 2004 14:27:14 -0000	1.8
+++ src/msgid.cc	14 Jun 2004 11:08:41 -0000
@@ -5,6 +5,8 @@
 #include "msgid.h"
 #include "options.h"
 #include <c-client.h>
+#undef max
+#undef min
 #include <cassert>
 
 //////////////////////////////////////////////////////////////////////////
Index: src/msgid.h
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/msgid.h,v
retrieving revision 1.2
diff -u -r1.2 msgid.h
--- src/msgid.h	1 Jun 2004 09:34:36 -0000	1.2
+++ src/msgid.h	14 Jun 2004 11:08:41 -0000
@@ -2,6 +2,8 @@
 
 #include <string>
 #include <c-client.h>
+#undef max
+#undef min
 #include "options.h"
 
 using namespace std;
Index: src/msgstring.c
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/msgstring.c,v
retrieving revision 1.3
diff -u -r1.3 msgstring.c
--- src/msgstring.c	20 Apr 2003 09:50:58 -0000	1.3
+++ src/msgstring.c	14 Jun 2004 11:08:41 -0000
@@ -4,6 +4,8 @@
 
 #include <stdio.h>      // required by c-client.h
 #include <c-client.h>
+#undef max
+#undef min
 #include "msgstring.h"
 
 STRINGDRIVER msg_string = {
Index: src/store.h
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/store.h,v
retrieving revision 1.7
diff -u -r1.7 store.h
--- src/store.h	14 Jun 2004 08:57:08 -0000	1.7
+++ src/store.h	14 Jun 2004 11:08:41 -0000
@@ -5,6 +5,8 @@
 #include <map>
 #include <set>
 #include <c-client.h>
+#undef max
+#undef min
 #include "types.h"
 #include "msgid.h"
 
Index: src/types.h
===================================================================
RCS file: /cvsroot/mailsync/mailsync/src/types.h,v
retrieving revision 1.6
diff -u -r1.6 types.h
--- src/types.h	23 Mar 2003 21:06:45 -0000	1.6
+++ src/types.h	14 Jun 2004 11:08:41 -0000
@@ -5,6 +5,8 @@
 #include <map>
 #include <set>
 #include <c-client.h>
+#undef max
+#undef min
 #include "msgid.h"
 
 using namespace std;

[Mailsync-list] new CVS snapshot

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

Hello everybody,

I've released a new CVS snapshot, which should fix both mh (tested a
bit) and mutt (messages are not shown as new - tested a bit) problems.

Please test. This is a release candidate (knocking on wood like a
woodpecker).

Thanks a greets for all the bugreporters and all those that are keeping on
bugging me about their pet mh store not working ;-)
*t

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

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

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

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

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

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

Love,
H

Re: [Mailsync-list] mh sync

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

On Wed, 9 Jun 2004, Tomas Pospisek wrote:

> On Sat, 5 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.
>
> > 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.

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

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

Re: [Mailsync-list] two build fixes

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

> > Functionality seems okay. But in case kerberos isn't required it will
> > has not AC_MSG_RESULT for AC_MSG_CHECKING. I'd add else clause to the
> > need_krb if with AC_MSG_RESULT([not required]) or something like that.
> 
> Is it better like this (see CVS)?

checking if kerberos is required and available for linking against c-client... not required
checking whether c-client requires ssl linkage... yes

Exactly!

Love,
H

Re: [Mailsync-list] minor problems with mailsync

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

On Wed, 9 Jun 2004, Tomas Pospisek wrote:

> MH specifically has a problem with the version in CVS. I'll have a look at
> Michael's patch and try to integrate it one of these two days and I'll let
> you know (posting to this list). So please hold your breath for two more
> days and try the CVS version then ;-). OK?

Its inside CVS. And a fresh tar.gz of it is out on the main page. Please
try enjoy and report how it works for you.
*t

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

Re: [Mailsync-list] mh sync

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

On Sat, 5 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.

> 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*!!!
*t

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

Re: [Mailsync-list] two build fixes

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

On Wed, 9 Jun 2004, Michael 'hacker' Krelin wrote:

> On Wed, Jun 09, 2004 at 03:05:44PM +0200, Tomas Pospisek wrote:
> > On Sat, 5 Jun 2004, Michael 'hacker' Krelin wrote:
> >
> > [correct checking for kerberos installation]
> >
> > There's yet another try at getting it right in CVS (ac_with_cclient).
> > Could you please have a look at it if it's done the *right way* now?
>
> Functionality seems okay. But in case kerberos isn't required it will
> has not AC_MSG_RESULT for AC_MSG_CHECKING. I'd add else clause to the
> need_krb if with AC_MSG_RESULT([not required]) or something like that.

Is it better like this (see CVS)?
*t

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

Re: [Mailsync-list] two build fixes

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

On Wed, Jun 09, 2004 at 03:05:44PM +0200, Tomas Pospisek wrote:
> On Sat, 5 Jun 2004, Michael 'hacker' Krelin wrote:
> 
> [correct checking for kerberos installation]
> 
> There's yet another try at getting it right in CVS (ac_with_cclient).
> Could you please have a look at it if it's done the *right way* now?

Functionality seems okay. But in case kerberos isn't required it will
has not AC_MSG_RESULT for AC_MSG_CHECKING. I'd add else clause to the
need_krb if with AC_MSG_RESULT([not required]) or something like that.

> Dekuji moc krat!

neni zac ;-)

Love,
H

Re: [Mailsync-list] two build fixes

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

On Sat, 5 Jun 2004, Michael 'hacker' Krelin wrote:

[correct checking for kerberos installation]

There's yet another try at getting it right in CVS (ac_with_cclient).
Could you please have a look at it if it's done the *right way* now?

Dekuji moc krat!
*t

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

Re: [Mailsync-list] minor problems with mailsync

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

On Mon, 7 Jun 2004 cil...@co... wrote:

> 2. A way to force the use of ssh only, disabling rsh.

I guess you did read the c-client docu, so I suggest you ask on the
c-client mailing list.

> 3. More general pattern matching in store definitions, or at least the ability
>    to exclude certain mailboxes. (There's an easy workaround using symbolic
>    links if both machines run UNIX.)

There's a patch to have multiple patterns here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110480

People have reported success with it. If you use it, then please let me
know how you fare with it.

If you want to write a patch for exclusion of patterns or general regexpr
(or even better Perl style) then be my guest :)
*t

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