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

Re: isync duplicated some, but not all messages when moving computers

[Mathieu A. <ma...@ma...>]

Le Wed, Dec 18, 2024 at 10:37:43PM +0100, Bence Ferdinandy a écrit :
> 
> On Wed Dec 18, 2024 at 21:29, Oswald Buddenhagen via isync-devel <isy...@li...> wrote:
> > On Wed, Dec 18, 2024 at 02:33:51PM +0100, Bence Ferdinandy wrote:
> >>it was probably not the best idea, but I moved computers, by coping all
> >>my
> >>maildir and isync config, but not the isync state (in retrospect, I probably
> >>should have done that).
> >>
> > yeah ...
> >
> >>I ran isync (1.5.0) and some emails got duplicated, but
> >>not everything and more heavily in Archive folders. Is this the
> >>expected behaviour?
> >>
> > no. i expect that there is some confounding factor.
> > maybe misleading sort order?
> > or some messages were never pushed up because of reasons?
> 
> There were probably messages never pulled, but who knows. Anyway, I'm now
> professional in mail de-duplication.

A while back, I collected all my various imap tools written in various
languages over the years into a single tool, and it does deduplication
removal, amongst other things:
https://crates.io/crates/imap-tools
https://gitlab.com/mat813/imap-tools-rs

Though you'll need "cargo" to install it.

-- 
Mathieu Arnold

Re: config working on Ubuntu not working an arch?

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

On Wed, Dec 18, 2024 at 10:53:23PM +0100, Bence Ferdinandy wrote:
>    F: >>> 2 AUTHENTICATE PLAIN <authdata>
>
>Now for Ubuntu I know I had to mess around SASL and even build
>moriyoshi/cyrus-sasl-xoauth2.git manually to make things work,

>but this doesn't look like an issue with that.
>
but it totally does. it's clearly not even trying to use oauth. it must
be something with that plugin, but i have no clue beyond that.

google whether you can enable some sasl debugging via env vars or config
files.

beyond that, i guess i'd strace it and see if it does anything
unexpected. compare with a trace from the working box maybe.

config working on Ubuntu not working an arch?

[Bence F. <be...@fe...>]

Hi,

sorry for a second round of having issues moving ... Hopefully the last.

My previous machine was running Ubuntu now I moved to CachyOS (arch btw).
I supposedly didn't change anything in my configs and I can actually send
messages with msmtp for my oauth accounts (gmail and outlook), but mbsync if
failing for both.

For example with `mbsync -D`:

    Connecting to imap.gmail.com (173.194.76.109:993)...
    Connection is now encrypted
    F: * OK Gimap ready for requests from 89.223.195.239 o37mb130304551wms
    F: >>> 1 CAPABILITY
    F: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER
    F: 1 OK Thats all she wrote! o37mb130304551wms
    Logging in...
    Authenticating with SASL mechanism PLAIN...
    F: >>> 2 AUTHENTICATE PLAIN <authdata>
    F: 2 NO [AUTHENTICATIONFAILED] Invalid credentials (Failure)
    IMAP command 'AUTHENTICATE PLAIN <authdata>' returned an error: [AUTHENTICATIONFAILED] Invalid credentials (Failure)

Since it's failing for _both_ in mbsync and both can send I'm assuming it must
be mbsync. Now for Ubuntu I know I had to mess around SASL and even build
moriyoshi/cyrus-sasl-xoauth2.git manually to make things work, but this doesn't
look like an issue with that. Currently I have the package installed from aur.

❯ paru -Qe | grep isync
isync 1.5.0-2.1

I'm a bit lost what can be going wrong here. Any ideas?

Thanks,
Bence

Re: isync duplicated some, but not all messages when moving computers

[Bence F. <be...@fe...>]

On Wed Dec 18, 2024 at 21:29, Oswald Buddenhagen via isync-devel <isy...@li...> wrote:
> On Wed, Dec 18, 2024 at 02:33:51PM +0100, Bence Ferdinandy wrote:
>>it was probably not the best idea, but I moved computers, by coping all
>>my
>>maildir and isync config, but not the isync state (in retrospect, I probably
>>should have done that).
>>
> yeah ...
>
>>I ran isync (1.5.0) and some emails got duplicated, but
>>not everything and more heavily in Archive folders. Is this the
>>expected behaviour?
>>
> no. i expect that there is some confounding factor.
> maybe misleading sort order?
> or some messages were never pushed up because of reasons?

There were probably messages never pulled, but who knows. Anyway, I'm now
professional in mail de-duplication.

>
>>I was hoping that without zero state, isync would just rescan and
>>match up everything nicely if slowly.
>>
> no, isync does not look at the content, not even message ids.
> one could implement that as a fallback if one was so inclined ...
>
>>For future reference? Is copying everything, including state the
>>preferred way of moving?
>>
> yes.
> unless your connection to the imap server is faster then a local
> transfer. then just sync up, and sync from scratch on the new box.

Well, now I know :)

Thanks,
Bence

Re: isync duplicated some, but not all messages when moving computers

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

On Wed, Dec 18, 2024 at 02:33:51PM +0100, Bence Ferdinandy wrote:
>it was probably not the best idea, but I moved computers, by coping all
>my
>maildir and isync config, but not the isync state (in retrospect, I probably
>should have done that).
>
yeah ...

>I ran isync (1.5.0) and some emails got duplicated, but
>not everything and more heavily in Archive folders. Is this the
>expected behaviour?
>
no. i expect that there is some confounding factor.
maybe misleading sort order?
or some messages were never pushed up because of reasons?

>I was hoping that without zero state, isync would just rescan and
>match up everything nicely if slowly.
>
no, isync does not look at the content, not even message ids.
one could implement that as a fallback if one was so inclined ...

>For future reference? Is copying everything, including state the
>preferred way of moving?
>
yes.
unless your connection to the imap server is faster then a local
transfer. then just sync up, and sync from scratch on the new box.

isync duplicated some, but not all messages when moving computers

[Bence F. <be...@fe...>]

Hi,

it was probably not the best idea, but I moved computers, by coping all my
maildir and isync config, but not the isync state (in retrospect, I probably
should have done that). I ran isync (1.5.0) and some emails got duplicated, but
not everything and more heavily in Archive folders. Is this the expected
behaviour? I was hoping that without zero state, isync would just rescan and
match up everything nicely if slowly.

For future reference? Is copying everything, including state the preferred way
of moving?

Thanks,
Bence

synchronize Opentext/Groupwise Notes+Appointments?

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

Hi list,

I discovered that people are from time to time sending me "Notes"
instead of emails, or "Appointments". These seem to be something
different and are not synced by mbsync, making me miss messages and
appointments.

The anatomy of such an "appointment" is:
MESSAGE 	2 KB 
TEXT.htm 	6 KB 	
rfc2445.ics 	7 KB 	
Mime.822 	40 KB 

and of a "Note":
MESSAGE 	1 KB
text.htm 	1 KB 

Is there a way to sync them, or at least convert them on the server to
something that can be synced?

Thanks!
Peter

Re: Suddenly errors regarding "near side box INBOX/XXX cannot be opened."

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

On Sun, Dec 08, 2024 at 09:23:11AM +0100, Johannes Kastl wrote:
>> Error: channel XXX: near side box INBOX/20140102_BACKUP cannot be opened.
>
>I can send the log directly, if it is any help?
>
yes, but let's go for the complete set:
- your config file
- cd <local Path>; find -type d
- mbsync -D -ls
- mbsync -D -l <channel>
- mbsync -D <channel>

Re: Suddenly errors regarding "near side box INBOX/XXX cannot be opened."

[Johannes K. <ma...@oj...>]

Hi all,

On 04.12.24 06:43 Johannes Kastl wrote:
> Hi Oswald,
> 
> On 02.12.24 11:28 Oswald Buddenhagen via isync-devel wrote:
>> On Sun, Dec 01, 2024 at 08:47:48PM +0100, Johannes Kastl wrote:
>>>> Error: channel YYY: near side box INBOX/XXX cannot be opened.
>>>
>>>Funnily enough, in one case this happened after the folder was created
>>>locally and the sync succeeded. On the next run the error above was shown.
>>>
>> weird. try 'mbsync -ls' for starters.
>> if that looks good, try 'mbsync -l'.
>> if that still looks good, it's presumably not a user error.
>> in that case try syncing only one failing mailbox (YYY:INBOX/XXX).
>> add -D to the above command and the normal YYY run, und mail me the
>> logs.
> 
> Will try to do some more debugging.

Hmmm, I find no obvious errors (at least, obvious to me...):

> Opening far side box INBOX/20140102_BACKUP...
> F: [ 10] Enter open_box
> F: >>> 7 SELECT "INBOX/20140102_BACKUP"^M
> F: [ 10] Leave open_box 
> Opening near side box INBOX/20140102_BACKUP...
> F: [ 7] Callback leave load_box
> F: * 97 EXISTS
> F: * 0 RECENT 
> F: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
> F: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Unlimited
> F: * OK [UIDNEXT 1396] Predicted next UID
> F: * OK [UIDVALIDITY 1388669892] UIDs valid
> F: 7 OK [READ-WRITE] SELECT completed
> F: [ 10] Callback enter open_box, sts=0, uidvalidity=1388669892
> Error: channel XXX: near side box INBOX/20140102_BACKUP cannot be opened.
> F: Called get_caps, ret=0x7
> N: Called get_caps, ret=0

And the same for all children of this folder.

I can send the log directly, if it is any help?

Kind Regards,
Johannes

Re: Repeatable crash in 1.5.0

[Robin P. <rlp...@di...>]

Awesome, thanks!

On Sat, Dec 7, 2024 at 12:47 AM Oswald Buddenhagen via isync-devel <
isy...@li...> wrote:

> On Fri, Dec 06, 2024 at 05:07:49PM -0800, Robin Lee Powell via isync-devel
> wrote:
> >mbsync: socket.c:957: socket_read: Assertion `min_len <= max_len' failed.
> >
> this is already fixed in master as of a few days ago.
>
>
> _______________________________________________
> isync-devel mailing list
> isy...@li...
> https://lists.sourceforge.net/lists/listinfo/isync-devel
>

Re: Repeatable crash in 1.5.0

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

On Fri, Dec 06, 2024 at 05:07:49PM -0800, Robin Lee Powell via isync-devel wrote:
>mbsync: socket.c:957: socket_read: Assertion `min_len <= max_len' failed.
>
this is already fixed in master as of a few days ago.

Repeatable crash in 1.5.0

[Robin L. P. <rlp...@di...>]

I have sync set up for my gmail to local maildir, it's been working
fine for months.

I recently updated my system and went from (probably)
isync-0:1.4.4-5.fc37.x86_64 to (definitely)
isync-0:1.5.0-2.fc41.x86_64 , and now it does this:

    Opening far side box [Gmail]/Chats...
    Opening near side box [Gmail]/Chats...
    Loading far side box...
    Loading near side box...
    near side: 503 messages, 0 recent
    far side: 938 messages, 0 recent
    Synchronizing...
    C: 0/1  B: 34/44  F: +2/2 *0/0 #0/0 -0/0  N: +2/437 *2/2 #0/0 -0/0mbsync: socket.c:957: socket_read: Assertion `min_len <= max_len' failed.
    [2]    3876479 IOT instruction (core dumped)  mbsync -V gmail

I don't actually care about the Chats folder (it's had no activity
in ~10 years), but since it does this with perfect reliability, I thought y'all
my be interested in exploring it as a possible bug; lemme know how I can help.

Re: IMAP Timeouts During Local Operations—Correct Behaviour?

[Sabahattin G. <lis...@me...>]

On 4 Dec 2024, at 09:31, Oswald Buddenhagen via isync-devel <isy...@li...> wrote:
> On Tue, Dec 03, 2024 at 04:12:09PM +0000, Sabahattin Gucukoglu via isync-devel wrote:
>> So my question is this: is it expected behaviour that timeouts occur
>> because of long local operations,
>> 
> yes, sort of.
> 
>> and is it *correct* or desirable behaviour?
>> 
> certainly not desirable.

Agreed. It’s just not intuitive IMO and is not what one would expect from a control intended to detect unreachability. Yes, it’s sort of obvious that it happens at all because by the time a response is expected that much time has passed. But of course the delay is being imposed by mbsync and not the server.

>> Isn’t the “right thing” here to have a dedicated idle timeout, which
>> would take effect while isync is doing purely local computation?
>> 
> is that timeout reported by isync or the server? what's the end of the
> log with -Dn?

Reported by mbsync. Here are the log lines starting with the opening of the problem mailbox:
Opening far side box GRC...
>>> 32 SELECT "GRC"
Opening near side box GRC...
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1692709377]
* OK [UIDNEXT 1]
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen \Recent $MailFlagBit0 $MailFlagBit1 $MailFlagBit2 $Forwarded Redirected $NotJunk NotJunk)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \Recent $MailFlagBit0 $MailFlagBit1 $MailFlagBit2 $Forwarded Redirected $NotJunk NotJunk $iCloudCleanup \*)]
32 OK [READ-WRITE] SELECT completed (took 2 ms)
Loading far side box...
far side: 0 messages, 0 recent
Warning: lost track of 1018382 pushed message(s)
Loading near side box...
near side: 1018382 messages, 1018382 recent
Synchronizing...
>>> 33 APPEND "GRC" "04-Dec-2024 18:25:24 +0000" {7001}
Socket error on imap.mail.me.com (17.42.251.69:993): timeout.

That APPEND is the very first message in the mailbox. With even more debugging I see that every other near-far transaction is pending right before the timeout occurs. That “lost track” warning seems to be about uncommitted messages from the last failed attempt, but as you see not a single APPEND was actually successful, so it’s fine. I initially wasn’t really willing to download all the source messages again, so that was fortunate. But as it happens running mbsync interactively with a 300 second timeout (see below) was still giving me lots of “Server too busy” warnings from the IMAP server anyway, so I was willing to start again fresh from source for science.

>> I am successfully working around this situation by using a separate
>> config file for the duration of the initial upload [...]
>> 
> how is it different?

Sorry. Increase timeout from 30 to 300s. It is now running in background; it’s too slow and painful to watch interactively, so I’m hoping it’ll complete over the course of a few days. It is however making the IMAP server very grumpy and I seem to be pushing some limit or other because it sometimes just refuses to store a message, or disconnects me. I can’t wait to finish setting up my self-hosted mail again after years.

> my first idea would be to limit the operations to the minimum, in your
> case that should be --push-new if i understand your case correctly.

Yes, I’ll look into this, thanks, although it now seems to be on the rails.

> secondly, if the problem is local i/o and you're pushing, then copying
> the box to a ram drive might be a solution. (make sure to move the state
> file into place when switching back to the proper box.)
> 
> did you try to identify what the time is actually spent on? i'd first
> try htop and iotop, and then for finer results valgrind/cachegrind and
> strace -tt, resp.

Interesting idea re the ramdisk! I will probably try that next if I need to, though I’m hoping the 30s timeout will be acceptable again after the initial transfer.

This is macOS so I’ll need to look at the equivalents, however a quick look at ActivityMonitor doesn’t show substantial disk I/O at all, less than 10 K/s, so we’re probably being held back by latency here.

Thanks for the help.

Cheers,
Sabahattin

Re: [commit] master: build: also consider builds off of git with `git clone --depth 1`

[Paymon <dar...@gm...>]

On Wed, Dec 04, 2024 at 05:28:33PM +0100, Oswald Buddenhagen via isync-devel wrote:
> but maybe this could be still handled better? i guess not, as the branch
> name above is meaningless, and presumably no other refs are present?  does
> gitk --all show anything sensible in this repo?

it's a remote machine with wayland only.
what would `gitk --all show` tell us? (never used it before)
people at #git tell me to use `git log --all`... and there is something:

```sh
portage@frostbite /var/tmp/portage/net-mail/isync-9999/work/isync-9999 $ git --no-pager log --all
commit 884413b48871361cf6c0cfa41d01c22ed1ec8d30 (grafted, HEAD)
Author: Paymon MARANDI <dar...@gm...>
Date:   Tue Dec 3 15:25:09 2024 -0500

    build: also consider builds off of git with `git clone --depth 1`

    one case where this could happen is a shallow clone, purely for build
    purposes. in source based distros, like gentoo, setting depth of the
    clone to 1, globally, is a common configuration. this patch avoids that
    those builds fail.

    Signed-off-by: Paymon MARANDI <dar...@gm...>
```

```sh
portage@frostbite /var/tmp/portage/net-mail/isync-9999/work/isync-9999 $ cat .git/refs/git-r3/HEAD
884413b48871361cf6c0cfa41d01c22ed1ec8d30
```

git-r3 is poratge's doing. (portage is the package manager in gentoo).

-- 

               Paymon

Re: [commit] master: build: also consider builds off of git with `git clone --depth 1`

[Oswald B. <os...@us...>]

On Wed, Dec 04, 2024 at 11:15:29AM -0500, Paymon wrote:
>spoke to early; it's git-branch that returns something like this:
>* (HEAD detached at refs/git-r3/HEAD)
>
>that escapes our regex.
>
>i would pass `--always` unconditionally to be defensive about it; what do you
>think?
>
i did that, with a forced push, because i'm evil like that.

but maybe this could be still handled better? i guess not, as the branch 
name above is meaningless, and presumably no other refs are present?  
does gitk --all show anything sensible in this repo?

Re: [commit] master: build: also consider builds off of git with `git clone --depth 1`

[Paymon <dar...@gm...>]

you beat me to it; please discard the other patch.

-- 

               Paymon

build: take count of detached HEAD

[Paymon <dar...@gm...>]

-- 

               Paymon

[commit] master: build: also consider builds off of git with `git clone --depth 1`

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

commit 884413b48871361cf6c0cfa41d01c22ed1ec8d30
Author:     Paymon MARANDI <dar...@gm...>
AuthorDate: Tue Dec 3 15:25:09 2024 -0500
Commit:     Oswald Buddenhagen <os...@us...>
CommitDate: Wed Dec 4 17:20:49 2024 +0100

    build: also consider builds off of git with `git clone --depth 1`
    
    one case where this could happen is a shallow clone, purely for build
    purposes. in source based distros, like gentoo, setting depth of the
    clone to 1, globally, is a common configuration. this patch avoids that
    those builds fail.
    
    Signed-off-by: Paymon MARANDI <dar...@gm...>

 version.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/version.sh b/version.sh
index fc1ed7d..669f1b6 100755
--- a/version.sh
+++ b/version.sh
@@ -17,12 +17,12 @@ if test -z "$mb"; then
 fi
 if test -z "$mb"; then
 	# still no upstream, so just describe HEAD as-is.
-	gver=$(git describe --tags HEAD)
+	gver=$(git describe --always --tags HEAD)
 else
 	# find out whether we have local work, and if so, collapse it into
 	# a single suffix. otherwise, we'd cause pointless rebuilds during
 	# development.
-	gver=$(git describe --tags $mb)
+	gver=$(git describe --always --tags $mb)
 	lcl=$(git rev-list -n 1 $mb..HEAD)
 	if test -n "$lcl"; then
 		gver="$gver-plus"

[commit] branch 'master' rewound

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

The branch 'master', previously at 8920b6a, has been rewound by 1
revision(s) to 15c7e02.

Re: [commit] master: build: also consider builds off of git with `git clone --depth 1`

[Paymon <dar...@gm...>]

On Wed, Dec 04, 2024 at 10:50:43AM -0500, Paymon wrote:
> On Wed, Dec 04, 2024 at 08:41:44AM +0000, ossi via isync-devel wrote:
> > commit 8920b6a1db443aac00783f7754a05852bb1bc71c
> > Author:     Paymon MARANDI <dar...@gm...>
> > AuthorDate: Tue Dec 3 15:25:09 2024 -0500
> > Commit:     Oswald Buddenhagen <os...@us...>
> > CommitDate: Wed Dec 4 09:36:28 2024 +0100
> > 
> >     build: also consider builds off of git with `git clone --depth 1`
> >     
> >     one case where this could happen is a shallow clone, purely for build
> >     purposes. in source based distros, like gentoo, setting depth of the
> >     clone to 1, globally, is a common configuration. this patch avoids that
> >     those builds fail.
> >     
> >     Signed-off-by: Paymon MARANDI <dar...@gm...>
> > 
> >  version.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/version.sh b/version.sh
> > index fc1ed7d..5dfc61b 100755
> > --- a/version.sh
> > +++ b/version.sh
> > @@ -22,7 +22,7 @@ else
> >  	# find out whether we have local work, and if so, collapse it into
> >  	# a single suffix. otherwise, we'd cause pointless rebuilds during
> >  	# development.
> > -	gver=$(git describe --tags $mb)
> > +	gver=$(git describe --always --tags $mb)
> >  	lcl=$(git rev-list -n 1 $mb..HEAD)
> >  	if test -n "$lcl"; then
> >  		gver="$gver-plus"
> > 
> > 
> 
> it turns out that this doesn't cover the gentoo case. $mb is always going to
> come up empty! i should have tested... i will submit a revised version.
> 
> -- 
> 
>                Paymon

spoke to early; it's git-branch that returns something like this:
* (HEAD detached at refs/git-r3/HEAD)

that escapes our regex.

i would pass `--always` unconditionally to be defensive about it; what do you
think?

-- 

               Paymon

Re: [commit] master: build: also consider builds off of git with `git clone --depth 1`

[Oswald B. <os...@us...>]

On Wed, Dec 04, 2024 at 10:50:43AM -0500, Paymon wrote:
>> +++ b/version.sh
>> @@ -22,7 +22,7 @@ else
>>  	# find out whether we have local work, and if so, collapse it into
>>  	# a single suffix. otherwise, we'd cause pointless rebuilds during
>>  	# development.
>> -	gver=$(git describe --tags $mb)
>> +	gver=$(git describe --always --tags $mb)
>>  	lcl=$(git rev-list -n 1 $mb..HEAD)
>>  	if test -n "$lcl"; then
>>  		gver="$gver-plus"
>> 
>> 
>
>it turns out that this doesn't cover the gentoo case. $mb is always going to
>come up empty! i should have tested... i will submit a revised version.
>
interesting.
i originally thought that the other branch should be covered, but then i 
tested it with a local shallow clone, and the merge base was always the 
commit itself.
what's the difference?

Re: [commit] master: build: also consider builds off of git with `git clone --depth 1`

[Paymon <dar...@gm...>]

On Wed, Dec 04, 2024 at 08:41:44AM +0000, ossi via isync-devel wrote:
> commit 8920b6a1db443aac00783f7754a05852bb1bc71c
> Author:     Paymon MARANDI <dar...@gm...>
> AuthorDate: Tue Dec 3 15:25:09 2024 -0500
> Commit:     Oswald Buddenhagen <os...@us...>
> CommitDate: Wed Dec 4 09:36:28 2024 +0100
> 
>     build: also consider builds off of git with `git clone --depth 1`
>     
>     one case where this could happen is a shallow clone, purely for build
>     purposes. in source based distros, like gentoo, setting depth of the
>     clone to 1, globally, is a common configuration. this patch avoids that
>     those builds fail.
>     
>     Signed-off-by: Paymon MARANDI <dar...@gm...>
> 
>  version.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/version.sh b/version.sh
> index fc1ed7d..5dfc61b 100755
> --- a/version.sh
> +++ b/version.sh
> @@ -22,7 +22,7 @@ else
>  	# find out whether we have local work, and if so, collapse it into
>  	# a single suffix. otherwise, we'd cause pointless rebuilds during
>  	# development.
> -	gver=$(git describe --tags $mb)
> +	gver=$(git describe --always --tags $mb)
>  	lcl=$(git rev-list -n 1 $mb..HEAD)
>  	if test -n "$lcl"; then
>  		gver="$gver-plus"
> 
> 

it turns out that this doesn't cover the gentoo case. $mb is always going to
come up empty! i should have tested... i will submit a revised version.

-- 

               Paymon

Re: IMAP Timeouts During Local Operations—Correct Behaviour?

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

On Tue, Dec 03, 2024 at 04:12:09PM +0000, Sabahattin Gucukoglu via isync-devel wrote:
>So my question is this: is it expected behaviour that timeouts occur
>because of long local operations,
>
yes, sort of.

>and is it *correct* or desirable behaviour?
>
certainly not desirable.

>Isn’t the “right thing” here to have a dedicated idle timeout, which
>would take effect while isync is doing purely local computation?
>
is that timeout reported by isync or the server? what's the end of the
log with -Dn?

if it's the server, then it's quite some work to fix - the maildir
driver would have to be made asynchronous (possibly threaded).

>I am successfully working around this situation by using a separate
>config file for the duration of the initial upload [...]
>
how is it different?

my first idea would be to limit the operations to the minimum, in your
case that should be --push-new if i understand your case correctly.

secondly, if the problem is local i/o and you're pushing, then copying
the box to a ram drive might be a solution. (make sure to move the state
file into place when switching back to the proper box.)

did you try to identify what the time is actually spent on? i'd first
try htop and iotop, and then for finer results valgrind/cachegrind and
strace -tt, resp.

[commit] master: build: also consider builds off of git with `git clone --depth 1`

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

commit 8920b6a1db443aac00783f7754a05852bb1bc71c
Author:     Paymon MARANDI <dar...@gm...>
AuthorDate: Tue Dec 3 15:25:09 2024 -0500
Commit:     Oswald Buddenhagen <os...@us...>
CommitDate: Wed Dec 4 09:36:28 2024 +0100

    build: also consider builds off of git with `git clone --depth 1`
    
    one case where this could happen is a shallow clone, purely for build
    purposes. in source based distros, like gentoo, setting depth of the
    clone to 1, globally, is a common configuration. this patch avoids that
    those builds fail.
    
    Signed-off-by: Paymon MARANDI <dar...@gm...>

 version.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/version.sh b/version.sh
index fc1ed7d..5dfc61b 100755
--- a/version.sh
+++ b/version.sh
@@ -22,7 +22,7 @@ else
 	# find out whether we have local work, and if so, collapse it into
 	# a single suffix. otherwise, we'd cause pointless rebuilds during
 	# development.
-	gver=$(git describe --tags $mb)
+	gver=$(git describe --always --tags $mb)
 	lcl=$(git rev-list -n 1 $mb..HEAD)
 	if test -n "$lcl"; then
 		gver="$gver-plus"

Re: Suddenly errors regarding "near side box INBOX/XXX cannot be opened."

[Johannes K. <ma...@oj...>]

Hi Oswald,

On 02.12.24 11:28 Oswald Buddenhagen via isync-devel wrote:
> On Sun, Dec 01, 2024 at 08:47:48PM +0100, Johannes Kastl wrote:
>>> Error: channel YYY: near side box INBOX/XXX cannot be opened.
>>
>>Funnily enough, in one case this happened after the folder was created
>>locally and the sync succeeded. On the next run the error above was shown.
>>
> weird. try 'mbsync -ls' for starters.
> if that looks good, try 'mbsync -l'.
> if that still looks good, it's presumably not a user error.
> in that case try syncing only one failing mailbox (YYY:INBOX/XXX).
> add -D to the above command and the normal YYY run, und mail me the
> logs.

Will try to do some more debugging.

>>I also noticed that my GMX mailboxes suddenly stop using Entw&rfe
>>locally, but use the proper German "Entwürfe". I am not sure if this
>>is related or something that has changed on the provider's side?
>>
> v1.5 gained proper support for UTF-7 & UTF-8, so your pre-existing local
> folders need to be renamed.
> it's possible that this is in fact the root cause of the above problem,
> but that depends on your exact config.

Only the name of the drafts folder changed, the folder that cannot be
synced have not changed and still have the same name.

Kind Regards,
Johannes