isync-devel — All-purpose list, actually - but RTFM first. Moderated for non-subscribers for SPAM protection.

Re: IMAP pull-and-delete operation

[Evgeniy B. <bi...@pr...>]

On Sun, Nov 16, 2025 at 07:12:20PM +0000, synflower--- via isync-devel wrote:
> Is the MaxMessages code so buggy or poorly tested
> that it's necessary, though?

 When you're going to use a tool which is not designed for your task,
 you take on a role of tester.
-- 
 Eugene Berdnikov

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Mon, Nov 10, 2025 at 12:33:32PM +0100, Philippe Bruhat (BooK) wrote:
>> isync's purpose is to keep both sides in sync. MaxMessages is a deviation
>> from that. when you push that number down to zero, that's _literally_
>> extreme, and you've gone from syncing to fetching.
>
>Can't the requested workflow be simply scripted as:
>- synchronize with isync (getting all the emails from the remote)
>- move all the email to a non-synchronized folder (emptying the local)
>- synchronize again (removing all emails from the remote)

...yes, I suppose so. Is the MaxMessages code so buggy or poorly tested
that it's necessary, though? 

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Mon, Nov 10, 2025 at 10:05:09AM +0100, Oswald Buddenhagen via isync-devel wrote:
>>What is so extreme about what I am doing?
>>
>isync's purpose is to keep both sides in sync. MaxMessages is a 
>deviation from that. when you push that number down to zero, that's 
>_literally_ extreme, and you've gone from syncing to fetching.

Well, yes. But I meant more in the programming sense. Why would reducing
MaxMessages result in a higher likelyhood of something going wrong, and
e.g messages being lost?

>because MaxMessage doesn't really fit the basic scheme, its 
>implementation actually comes at a rather significant cost in 
>complexity; it's easily the most difficult part of the whole codebase.
>i don't know if it would be difficult to make it support zero; it 
>might just work with a few minor changes. patches (with autotests) 
>welcome.

I wee. I will take a look. But be careful what you wish for: the last
time I wrote C code was right after reading K&R... and just before the
Yahoo IPO.

Re: Evade forced external mail archive. Was: Sync IMAP Mailboxes/Folders via ssh?

[Rene K. <ma...@rk...>]

On Fri, Nov 14, 2025 at 06:20:52AM +0100, Peter P. wrote:
> Hi list,
> 
> reviving an older thread here, I am still looking for a solution to the
> problem of my employer wanting to move all email in my account older than X
> years from all folders and host it on a separate webservice[1], thus
> making it inaccessible to me from isync/mutt/notmuch etc.
> The employer is trying to save storage and server ressources this way
> and this questionable move is unavoidable for me.
> 
> Denial Tamling has suggested using tools from the mblaze package to filter
> mail older than a certain date, with Oswald pointing out a pitfall when
> moving these messages, which I don't yet understand:
> 
> * Oswald Buddenhagen via isync-devel <isy...@li...> [2025-07-18 09:02]:
> > On Thu, Jul 17, 2025 at 10:33:36PM +0200, Daniel Tameling wrote:
> > >  mv $(mlist ./INBOX | mpick -t 'from =~ "@github"') ./github/cur
> > > 
> > this will preserve the ,U=nnn infixes of the files, which is a very bad
> > idea.
> 
> Is there a correct way to move all mail from all folders older than X to
> some other folder?
> 
> I am wondering if mblaze/mlist is nevertheless the best way I can
> anticipate the forced archival.

I'd guess that using mrefile(1) should do it the correct way.

> If I would manage to hereby extract all old email from all far-side
> folders I would then need to store it to a near-side folder that is not
> synced back to the far side. How could I nevertheless keep that
> near-side folder in sync across multiple computers? 

By using another IMAP server - which is probably against some rules
about corporate stuff.

> Is there any other way to work around this imminent problem?

As long as you are not deleting anything from the archive, as emails are
just text and files, any method to sync text and files should do.

Evade forced external mail archive. Was: Sync IMAP Mailboxes/Folders via ssh?

[Peter P. <pet...@fa...>]

Hi list,

reviving an older thread here, I am still looking for a solution to the
problem of my employer wanting to move all email in my account older than X
years from all folders and host it on a separate webservice[1], thus
making it inaccessible to me from isync/mutt/notmuch etc.
The employer is trying to save storage and server ressources this way
and this questionable move is unavoidable for me.

Denial Tamling has suggested using tools from the mblaze package to filter
mail older than a certain date, with Oswald pointing out a pitfall when
moving these messages, which I don't yet understand:

* Oswald Buddenhagen via isync-devel <isy...@li...> [2025-07-18 09:02]:
> On Thu, Jul 17, 2025 at 10:33:36PM +0200, Daniel Tameling wrote:
> >  mv $(mlist ./INBOX | mpick -t 'from =~ "@github"') ./github/cur
> > 
> this will preserve the ,U=nnn infixes of the files, which is a very bad
> idea.

Is there a correct way to move all mail from all folders older than X to
some other folder?

I am wondering if mblaze/mlist is nevertheless the best way I can
anticipate the forced archival.

If I would manage to hereby extract all old email from all far-side
folders I would then need to store it to a near-side folder that is not
synced back to the far side. How could I nevertheless keep that
near-side folder in sync across multiple computers? 

Is there any other way to work around this imminent problem?

Thank you so much!
best, Peter

[1] https://www.opentext.com/products/retain-unified-archiving

Re: IMAP pull-and-delete operation

[Philippe B. (BooK) <phi...@br...>]

On Mon, Nov 10, 2025 at 10:05:09AM +0100, Oswald Buddenhagen via isync-devel wrote:
> On Mon, Nov 10, 2025 at 08:31:55AM +0000, syn...@da... wrote:
> > On Fri, Oct 31, 2025 at 12:15:55PM +0100, Oswald Buddenhagen via isync-devel wrote:
> > > shoehorning isync into doing something it was not designed for
> > 
> > What is so extreme about what I am doing?
> > 
> isync's purpose is to keep both sides in sync. MaxMessages is a deviation
> from that. when you push that number down to zero, that's _literally_
> extreme, and you've gone from syncing to fetching.

Can't the requested workflow be simply scripted as:
- synchronize with isync (getting all the emails from the remote)
- move all the email to a non-synchronized folder (emptying the local)
- synchronize again (removing all emails from the remote)

-- 
 Philippe Bruhat (BooK)

 People are all unique- but some are more unique than others.
                                    (Moral from Groo The Wanderer #22 (Epic))

Re: IMAP pull-and-delete operation

[Oswald B. <osw...@gm...>]

On Mon, Nov 10, 2025 at 08:31:55AM +0000, syn...@da... wrote:
>On Fri, Oct 31, 2025 at 12:15:55PM +0100, Oswald Buddenhagen via isync-devel wrote:
>>shoehorning isync into doing something it was not designed for
>
>What is so extreme about what I am doing?
>
isync's purpose is to keep both sides in sync. MaxMessages is a 
deviation from that. when you push that number down to zero, that's 
_literally_ extreme, and you've gone from syncing to fetching.

>Why is this such a difficult task for isync?
>
because MaxMessage doesn't really fit the basic scheme, its 
implementation actually comes at a rather significant cost in 
complexity; it's easily the most difficult part of the whole codebase.
i don't know if it would be difficult to make it support zero; it might 
just work with a few minor changes. patches (with autotests) welcome.

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Fri, Oct 31, 2025 at 12:15:55PM +0100, Oswald Buddenhagen via isync-devel wrote:
>shoehorning isync into doing something it was 
>not designed for

What is so extreme about what I am doing? Why is this such a difficult
task for isync?

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Fri, Oct 31, 2025 at 12:15:55PM +0100, Oswald Buddenhagen via isync-devel wrote:
>why are you insisting on shoehorning isync into doing something it was 
>not designed for?

For one, I've been using isync for years and I have a lot of different
systems set up using it. Isync works great and I know my configuration
works. If I have to change over to Fetchmail then that's a massive
headache.

> just use fetchmail, as i suggested in my first response.

Fetchmail is, as far as I can tell, fundamentally different from isync.
I can't just write a script to convert my .mbsyncrc into a .fetchmailrc
and then have it drop mail into the same Maildir.

It looks like I have to set up fetchmail to deliver to procmail for
every account, and then have procmail write out to the Maildir.

What's more, I can't find any documentation for this workflow, just bits
and pieces. That suggests I'm going to run into hidden gotchas and more
headaches.

So if I can stick to isync (fast, functional) instead of building up a
whole new system (hic sunt dracones) that's obviously preferable.

Re: IMAP pull-and-delete operation

[Oswald B. <osw...@gm...>]

On Fri, Oct 31, 2025 at 10:27:01AM +0000, syn...@da... wrote:
>I tested it and it works. For data protection reasons, it would be very
>useful if it was possible to set
>	MaxMessage 0
>and have this result in zero messages being left on the server.
>
why are you insisting on shoehorning isync into doing something it was 
not designed for? just use fetchmail, as i suggested in my first 
response.

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Tue, Oct 07, 2025 at 01:46:42PM +0200, Oswald Buddenhagen via isync-devel wrote:
>On Tue, Oct 07, 2025 at 11:36:56AM +0000, syn...@da... wrote:
>>If I configure
>>	MaxMessages 1
>>	ExpireUnread yes
>>	ExpireSide Far
>>that will result in all emails staying locally archived, but only the
>>most recent message remaining on the server? (excluding flagged
>>messages)
>>
>theoretically yes, though such an extreme value might derail it one 
>way or another (it's certainly not auto-tested). give it shot with a 
>low-value mailbox first.

I tested it and it works. For data protection reasons, it would be very
useful if it was possible to set
	MaxMessage 0
and have this result in zero messages being left on the server.

Currently setting the value to 0 disables MaxMessages. Therefore one
email is always left on the server, even though this email may contain
sensitive or personal information.

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Tue, Oct 07, 2025 at 01:46:42PM +0200, Oswald Buddenhagen via isync-devel wrote:
>On Tue, Oct 07, 2025 at 11:36:56AM +0000, syn...@da... wrote:
>>If I configure
>>	MaxMessages 1
>>	ExpireUnread yes
>>	ExpireSide Far
>>that will result in all emails staying locally archived, but only the
>>most recent message remaining on the server? (excluding flagged
>>messages)
>>
>theoretically yes, though such an extreme value might derail it one 
>way or another (it's certainly not auto-tested). give it shot with a 
>low-value mailbox first.

Is there a better way to achieve the desired result of "messages
archived locally, no messages left on the server"...?

Re: IMAP pull-and-delete operation

[Oswald B. <osw...@gm...>]

On Tue, Oct 07, 2025 at 11:36:56AM +0000, syn...@da... wrote:
>If I configure
>	MaxMessages 1
>	ExpireUnread yes
>	ExpireSide Far
>that will result in all emails staying locally archived, but only the
>most recent message remaining on the server? (excluding flagged
>messages)
>
theoretically yes, though such an extreme value might derail it one way 
or another (it's certainly not auto-tested). give it shot with a 
low-value mailbox first.

Re: IMAP pull-and-delete operation

[<syn...@da...>]

>we have at least one known user who achieves something to that effect 
>by using MaxMessages coupled with "ExpireSide Far".

If I configure
	MaxMessages 1
	ExpireUnread yes
	ExpireSide Far
that will result in all emails staying locally archived, but only the
most recent message remaining on the server? (excluding flagged
messages)


>
>if you want something even more "thorough", you need to use fetchmail 
>instead.
>
>
>_______________________________________________
>isync-devel mailing list
>isy...@li...
>https://lists.sourceforge.net/lists/listinfo/isync-devel

Re: IMAP pull-and-delete operation

[Oswald B. <osw...@gm...>]

On Mon, Oct 06, 2025 at 09:43:31PM +0000, synflower--- via isync-devel wrote:
>Therefore I need to find a way to achieve POP3-like pull-and-delete
>functionality on a server that only supports IMAP.
>
we have at least one known user who achieves something to that effect by 
using MaxMessages coupled with "ExpireSide Far".

if you want something even more "thorough", you need to use fetchmail 
instead.

IMAP pull-and-delete operation

[<syn...@da...>]

Hi all,
For data protection reasons, I do not want to leave my emails on the
mail server for all eternity.

Normally this would be easily accomplished by using POP3 as the sync
protocol, and instructing my email client to delete the mails after
downloading.

Unfortunately, many email providers have stopped supporting POP3!

Therefore I need to find a way to achieve POP3-like pull-and-delete
functionality on a server that only supports IMAP.

Lookin at the mbsync man page, it seems like I may be able to do this
using some combination of Sync options. But I am not quite sure which
ones to use.

How do I do this?

Thanks!

[commit] master: make imap_msgs test actually return non-zero on failure

[ossi <os...@us...>]

commit e13b9399c18fe714f9e759a791974fdf9206886a
Author: Oswald Buddenhagen <os...@us...>
Date:   Tue Mar 25 17:54:59 2025 +0100

    make imap_msgs test actually return non-zero on failure

 src/tst_imap_msgs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/tst_imap_msgs.c b/src/tst_imap_msgs.c
index f1df3d9..18f2965 100644
--- a/src/tst_imap_msgs.c
+++ b/src/tst_imap_msgs.c
@@ -90,8 +90,10 @@ verify( uint *in, const char *name )
 			break;
 		}
 	}
-	if (fails)
+	if (fails) {
 		dump_messages();
+		exit( 1 );
+	}
 }
 
 static void

[commit] master: clarify that maildir message moves should preserve the flag field

[ossi <os...@us...>]

commit 388e926e9e691c639d9ad832bc146af1cbcbf57c
Author: Oswald Buddenhagen <os...@us...>
Date:   Tue Aug 5 10:52:40 2025 +0200

    clarify that maildir message moves should preserve the flag field

 src/mbsync.1.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mbsync.1.in b/src/mbsync.1.in
index f48dad7..1a15b10 100644
--- a/src/mbsync.1.in
+++ b/src/mbsync.1.in
@@ -845,8 +845,9 @@ Mutt always does that, while mu4e needs to be configured to do it:
 .in -4
 .br
 The general expectation is that a completely new filename is generated
-as if the message was new, but stripping the \fB,U=\fIxxx\fR infix is
-sufficient as well.
+as if the message was new, except that the flag suffix (\fB:2,xxx\fR)
+needs to be preserved.
+But stripping the \fB,U=\fInnn\fR infix is sufficient as well.
 .
 .SH INHERENT PROBLEMS
 Changes done after \fBmbsync\fR has retrieved the message list will not be

[commit] master: mention that plain --debug excludes driver-all as well

[ossi <os...@us...>]

commit 23624e0fad12486515639b438b07d8e61f3dee72
Author: Oswald Buddenhagen <os...@us...>
Date:   Fri Aug 1 10:35:26 2025 +0200

    mention that plain --debug excludes driver-all as well
    
    amends 4cc5ad5a.

 src/mbsync.1.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mbsync.1.in b/src/mbsync.1.in
index 032918b..f48dad7 100644
--- a/src/mbsync.1.in
+++ b/src/mbsync.1.in
@@ -112,7 +112,8 @@ Enable debugging categories:
 \fBs\fR, \fBsync\fR - print synchronization debug info
 .in -4
 All categories except \fBcrash\fR implicitly enable \fIverbose\fR mode.
-Without category specification, all categories except net-all are enabled.
+Without category specification, all categories except net-all and driver-all
+are enabled.
 .TP
 \fB-q\fR, \fB--quiet\fR
 Suppress progress counters (this is implicit if stdout is no TTY,

[commit] master: fix conditional on undefined value on some config syntax errors

[ossi <os...@us...>]

commit e46fee23df79275cd897d51214a27391d3b822d6
Author: Oswald Buddenhagen <os...@us...>
Date:   Wed Mar 19 15:30:59 2025 +0100

    fix conditional on undefined value on some config syntax errors
    
    if the first token on a line was an unterminated escape/quote, we'd
    branch based on an uninitialized 'comment' variable.
    
    amends 725a122e.

 src/config.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/config.c b/src/config.c
index 3ea4837..6a98297 100644
--- a/src/config.c
+++ b/src/config.c
@@ -73,8 +73,8 @@ get_arg( conffile_t *cfile, int required, int *comment )
 	while ((c = *p) && isspace( (uchar)c ))
 		p++;
 	if (!c || c == '#') {
-		if (comment)
-			*comment = (c == '#');
+		if (comment && c)
+			*comment = 1;
 		if (required) {
 			error( "%s:%d: parameter missing\n", cfile->file, cfile->line );
 			cfile->err = 1;
@@ -313,7 +313,6 @@ int
 getcline( conffile_t *cfile )
 {
 	char *arg;
-	int comment;
 
 	if (cfile->rest && (arg = get_arg( cfile, ARG_OPTIONAL, NULL ))) {
 		error( "%s:%d: excess token '%s'\n", cfile->file, cfile->line, arg );
@@ -322,6 +321,7 @@ getcline( conffile_t *cfile )
 	while (fgets( cfile->buf, cfile->bufl, cfile->fp )) {
 		cfile->line++;
 		cfile->rest = cfile->buf;
+		int comment = 0;
 		if (!(cfile->cmd = get_arg( cfile, ARG_OPTIONAL, &comment ))) {
 			if (comment)
 				continue;

[commit] master: fix crash in mkdir_p() with invalid path

[ossi <os...@us...>]

commit d0e9ea471e2ce27cbb04b78cacaad81055468df1
Author: Oswald Buddenhagen <os...@us...>
Date:   Thu Sep 25 13:53:49 2025 +0200

    fix crash in mkdir_p() with invalid path
    
    if the user specified Inbox as a non-existing path in a directory they
    can't write to, we'd hit the root and crash due to a null pointer deref.
    
    REFMAIL: CAE...@ma...

 src/util.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/util.c b/src/util.c
index 121ab0a..c110188 100644
--- a/src/util.c
+++ b/src/util.c
@@ -796,6 +796,8 @@ mkdir_p( char *path, int len )
 	if (!mkdir( path, 0700 ) || errno == EEXIST)
 		return 0;
 	char *p = memrchr( path, '/', (size_t)len );
+	if (!p)
+		return -1;  // mkdir() already set errno
 	*p = 0;
 	if (mkdir_p( path, (int)(p - path) )) {
 		*p = '/';

Re: Segmentation fault : seems compatibility with glibc-2.42-r1

[Oswald B. <osw...@gm...>]

On Wed, Sep 03, 2025 at 11:34:25PM +0800, yueqr wrote:
>(gdb) bt
>...
>
that backtrace makes no sense at all; the stack is probably corrupted.

>I've noticed some mention from mail list  that varlingd may helped for more
>information, but I need some more time to know how to work with varlingd.
>
valgrind --tool=memcheck --num-callers=80 mbsync [...]

if libc is actually to blame in any way, it would make sense to install
the libc-dbgsym package (or whatever debug symbol packages are called on
your distro).

Segmentation fault : seems compatibility with glibc-2.42-r1

[yueqr <yu...@gm...>]

Since I've checked last time segmentation fault in mail list at 2024,  I
got some idea about how to get fault information. Since my majority doesn't
make any sense in CS knowledge, I have no more idea about how to get more
information. if any more specific information need to  be offer, please
inform me.

uname -a
Linux gentoo 6.16.4-gentoo-dist #1 SMP PREEMPT_DYNAMIC  x86_64 Intel(R)
Core(TM) i7-8750H CPU @ 2.20GHz GenuineIntel GNU/Linux

I'v specified CFLAGS with emerge(compiling) on isync: -g3 -pipe, and below
are  how  emerge actually did it:
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..   -D_GNU_SOURCE   -g3
-pipe -pipe -std=c11 -pedantic -Wall -Wextra -Wshadow -Wcast-qual
-Wformat=2 -Wformat-signedness -Wformat-nonliteral -Wstrict-prototypes
-Wno-overlength-strings -c -o util.o util.c

And same options for all other src files.

Here is what `mbsync -a -debug`:

isync 1.5.1 called with: '-a' '--debug'
Reading configuration file /home/moonsea/.config/isyncrc
merge ops (in Channel 'gmail-inbox'):
  common: OP_EXPUNGE,OP_CREATE
  far: XOP_HAVE_EXPUNGE,XOP_HAVE_CREATE
  near:
  => far: OP_EXPUNGE,OP_CREATE,XOP_HAVE_EXPUNGE,XOP_HAVE_CREATE
  => near: OP_EXPUNGE,OP_CREATE
......
F: 2 OK yu...@gm... authenticated (Success)
F: >>> 3 COMPRESS DEFLATE
F: 3 OK Success
F: >>> 4 ENABLE UTF8=ACCEPT
F: * ENABLED UTF8=ACCEPT
F: 4 OK Success
F: >>> 5 NAMESPACE
F: * NAMESPACE (("" "/")) NIL NIL
F: 5 OK Success
F: [ 1] Callback enter connect_store, sts=0
pattern 'INBOX' (effective 'INBOX'): no Path, INBOX
F: [ 4] Enter list_store, flags=1
F: >>> 6 LIST "" "*"
F: [ 4] Leave list_store
F: [ 1] Callback leave connect_store
F: * LIST (\HasNoChildren) "/" "INBOX"
F: * LIST (\HasChildren \Noselect) "/" "[Gmail]"
F: * LIST (\All \HasNoChildren) "/" "[Gmail]/All Mail"
F: * LIST (\Drafts \HasNoChildren) "/" "[Gmail]/Drafts"
F: * LIST (\HasNoChildren \Important) "/" "[Gmail]/Important"
F: * LIST (\HasNoChildren \Sent) "/" "[Gmail]/Sent Mail"
F: * LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam"
F: * LIST (\Flagged \HasNoChildren) "/" "[Gmail]/Starred"
F: * LIST (\HasNoChildren \Trash) "/" "[Gmail]/Trash"
F: 6 OK Success
F: [ 4] Callback enter list_store, sts=0
  [Gmail]/Trash
  [Gmail]/Starred
  [Gmail]/Spam
  [Gmail]/Sent Mail
  [Gmail]/Important
  [Gmail]/Drafts
  [Gmail]/All Mail
  INBOX
F: Called get_caps, ret=0x7
N: Called get_caps, ret=0
F: Enter select_box, name=INBOX
F: Leave select_box, ret=0
N: Enter select_box, name=INBOX
N: Leave select_box, ret=0
N: Called get_box_path, ret=/.mail/gmail/INBOX
Opening far side box INBOX...
F: [ 5] Enter open_box
F: >>> 7 SELECT "INBOX"
F: [ 5] Leave open_box
Opening near side box INBOX...
N: [ 6] Enter open_box
*** mbsync caught signal 11. Starting debugger ...
GNU gdb (Gentoo 16.3 vanilla) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /proc/493/exe...
(No debugging symbols found in /proc/493/exe)
Attaching to program: /proc/493/exe, process 493
Reading symbols from /usr/lib64/libssl.so.3...
(No debugging symbols found in /usr/lib64/libssl.so.3)
Reading symbols from /usr/lib64/libcrypto.so.3...
(No debugging symbols found in /usr/lib64/libcrypto.so.3)
Reading symbols from /usr/lib64/libz.so.1...
(No debugging symbols found in /usr/lib64/libz.so.1)
Reading symbols from /usr/lib64/libc.so.6...
(No debugging symbols found in /usr/lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
0x00007fb4feeba00a in ?? () from /usr/lib64/libc.so.6
(gdb) bt
#0  0x00007fb4feeba00a in ?? () from /usr/lib64/libc.so.6
#1  0x00007fb4feeba021 in ?? () from /usr/lib64/libc.so.6
#2  0x00007fb4fef1856b in wait4 () from /usr/lib64/libc.so.6
#3  0x000055a061eef7b9 in ?? ()
#4  <signal handler called>
#5  0x000055a061ec8847 in ?? ()
#6  0x000055a061ec8862 in ?? ()
#7  0x000055a061ec8862 in ?? ()
#8  0x000055a061ec8862 in ?? ()
#9  0x000055a061edeb2e in ?? ()
#10 0x000055a061ee07fe in ?? ()
#11 0x000055a061ed0913 in ?? ()
#12 0x000055a061ecfaa3 in ?? ()
#13 0x000055a061ed09c2 in ?? ()
#14 0x000055a061ee4390 in ?? ()
#15 0x000055a061ef33dd in ?? ()
#16 0x000055a061ef3181 in ?? ()
#17 0x000055a061ef2dd7 in ?? ()
#18 0x000055a061ed024b in ?? ()
#19 0x000055a061edac0b in ?? ()
#20 0x000055a061edabb4 in ?? ()
#21 0x000055a061ed2d6d in ?? ()
#22 0x000055a061ed745f in ?? ()
#23 0x000055a061ece188 in ?? ()
#24 0x000055a061ece2ac in ?? ()
#25 0x000055a061ece385 in ?? ()
#26 0x000055a061ecf1a6 in ?? ()
#27 0x000055a061ec94ec in ?? ()
#28 0x000055a061ec952c in ?? ()
#29 0x000055a061ef219d in ?? ()
#30 0x000055a061ef1086 in ?? ()
#31 0x00007fb4fee513eb in ?? () from /usr/lib64/libc.so.6
#32 0x00007fb4fee5149b in __libc_start_main () from /usr/lib64/libc.so.6
#33 0x000055a061ec6465 in ?? ()


`equery belong /usr/lib64/libc.so' told me the socket file is belong to
glibc-2.42-r1, so seems compatibility with current version of glibc?

I've noticed some mention from mail list  that varlingd may helped for more
information, but I need some more time to know how to work with varlingd.
If any more specific information need to been known,  please inform me.

Re: How to change SyncState without duplicating every message?

[Alan S. <ala...@po...>]

Hello,

On 2025-08-01 01:05, Oswald Buddenhagen via isync-devel <isy...@li...> writes:

> On Thu, Jul 31, 2025 at 12:53:06PM +0200, Alan Schmitt wrote:
>>- is there a way to remove all these duplicate emails?
>>
> any message-id based method will work for most mails. the list archive 
> contains several related threads.

Thank you, I forgot to search the archive. It seems that
https://github.com/kdeldycke/mail-deduplicate or using mutt (I should
really give it a try) is the way to go.

>>- for the last channel to migrate, how can I make sure emails are not
>>duplicated (ideally without having to download them again)?
>>
> by moving the state files from the old to the new location (as per 
> manual), while making sure that no sync is happening during the 
> migration.

I did not see how to do that in the man page
(https://isync.sourceforge.io/mbsync.html, searching for SyncState), but
with this hint I was able to copy the files in .mbsync to their correct
location. Thanks!

Alan

Re: How to change SyncState without duplicating every message?

[Oswald B. <osw...@gm...>]

On Thu, Jul 31, 2025 at 12:53:06PM +0200, Alan Schmitt wrote:
>- is there a way to remove all these duplicate emails?
>
any message-id based method will work for most mails. the list archive 
contains several related threads.

>- for the last channel to migrate, how can I make sure emails are not
>duplicated (ideally without having to download them again)?
>
by moving the state files from the old to the new location (as per 
manual), while making sure that no sync is happening during the 
migration.