Re: Losing emails

2022-07-01 Thread Oswald Buddenhagen
On Fri, Jul 01, 2022 at 11:21:46PM -0400, H wrote: Does anyone have any thoughts? could be just about anything. look for expiration settings in the clients and the web ui. you can try changing the access method (uning non-deleting POP3) or entirely stopping using specific clients (that would m

Losing emails

2022-07-01 Thread H
I have a problem tangentially related to mbsync and backing up mailboxes that I would appreciate any thoughts on. The email provider is Ionos, formerly 1&1, and the IMAP mailboxes are accessed by one computer and multiple phones/tablet. The computer uses Thunderbird (CentOS) albeit an older ver

Re: Tunnel failures

2022-07-01 Thread Yuri D'Elia
On Fri, Jul 01 2022, Oswald Buddenhagen wrote: > On Fri, Jul 01, 2022 at 06:03:15PM +0200, Yuri D'Elia wrote: >>Can the bigger buffering performed by ssh be an issue with the pipeline >>size, or it's unrelated? >> > the only way it could matter is if changed chunk size or timing > sufficiently to t

Re: Tunnel failures

2022-07-01 Thread Oswald Buddenhagen
On Fri, Jul 01, 2022 at 06:03:15PM +0200, Yuri D'Elia wrote: Can the bigger buffering performed by ssh be an issue with the pipeline size, or it's unrelated? the only way it could matter is if changed chunk size or timing sufficiently to trigger an otherwise unused and broken code path.

Re: Tunnel failures

2022-07-01 Thread Yuri D'Elia
On Fri, Jul 01 2022, Oswald Buddenhagen wrote: > On Fri, Jul 01, 2022 at 05:34:05PM +0200, Yuri D'Elia wrote: > make sure CRLF or other characters aren't mangled (i recently failed > piping a binary file through ssh from android to linux, so this is a > very real concern). > > you can try reverting

Re: Tunnel failures

2022-07-01 Thread Oswald Buddenhagen
On Fri, Jul 01, 2022 at 05:34:05PM +0200, Yuri D'Elia wrote: Socket error: receive buffer full. Probably protocol error. make sure CRLF or other characters aren't mangled (i recently failed piping a binary file through ssh from android to linux, so this is a very real concern). you can try r

Tunnel failures

2022-07-01 Thread Yuri D'Elia
I'm just trying a combination I've never tested before: connection via Tunnel. Whenever I use Tunnel, synchronization fails after a few hundred messages with: <...> Synchronizing... Socket error: receive buffer full. Probably protocol error. <...> However, I highly doubt it's a protocol error. T

[commit] master: abort channel sync when a store is fubar

2022-07-01 Thread Oswald Buddenhagen via isync-devel
commit 460bfbb8ac1eb3cb106bd816566f93ff66d2190f Author: Oswald Buddenhagen Date: Fri Jul 1 14:54:24 2022 +0200 abort channel sync when a store is fubar this got lost in d5a5da947. this also simplifies a nested condition, where the logic has previously been, but isn't a

Re: ext-exit documentation

2022-07-01 Thread Oswald Buddenhagen
On Fri, Jul 01, 2022 at 03:10:54PM +0200, Yuri D'Elia wrote: But I can definitely start taking a note if you want more detailed info in where it gets stuck. yes, please. make the external timeout long enough so that it accomodates isync's timeout on top of a reasonably worst-case time for a su

Re: ext-exit documentation

2022-07-01 Thread Yuri D'Elia
On Fri, Jul 01 2022, Oswald Buddenhagen wrote: > in short, it's a mess. Fully agree with this. > but if you find tangible evidence for isync's Timeout not working in > some other scenario, i'm all ears. > i suppose the most promising way to debug this would be running with -D > (maybe -Dn is suff

[commit] master: fix lineup of --ext-exit in help output

2022-07-01 Thread Oswald Buddenhagen via isync-devel
commit f6ccf9c4f5f343e4a1f457d3432134e7c61beb4a Author: Oswald Buddenhagen Date: Fri Jul 1 12:14:14 2022 +0200 fix lineup of --ext-exit in help output src/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/main.c b/src/main.c index 4607f5d..82da1ea 100644 --- a

[commit] master: improve wording of --ext-exit docu

2022-07-01 Thread Oswald Buddenhagen via isync-devel
commit 92faccc639aa9c8776dde1e2f32466454a2a89b0 Author: Oswald Buddenhagen Date: Fri Jul 1 13:00:01 2022 +0200 improve wording of --ext-exit docu src/mbsync.1 | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/mbsync.1 b/src/mbsync.1 index 8a8b01f..7157048 10064

Re: ext-exit documentation

2022-07-01 Thread Oswald Buddenhagen
On Fri, Jul 01, 2022 at 01:03:11PM +0200, Yuri D'Elia wrote: A good distinction could really be if retrying makes sense or not. yes, but the followup questions are then: retry after how much time, and how often? it's hard to know that if you don't know *exactly* what went wrong. otoh, network

Re: Crash during synchronization

2022-07-01 Thread Yuri D'Elia
On Fri, Jul 01 2022, Yuri D'Elia wrote: > Using the sources on the current main branch: > > | > | Logging in... > | Opening far side box INBOX... > | Opening near side box INBOX... > | Loading near side box... > | near side: 318 messages, 0 recent > | Loading far side box... > | far side: 462 mess

Re: ext-exit documentation

2022-07-01 Thread Yuri D'Elia
On Fri, Jul 01 2022, Oswald Buddenhagen wrote: > yeah, i've been pondering this, and i'm somewhat undecided how to go > about it. the problem is that there are lots of conditions, and how one > "condenses" them into a single flag is somewhat arbitrary. my current > thinking is that it would be bett

Re: ext-exit documentation

2022-07-01 Thread Yuri D'Elia
On Fri, Jul 01 2022, Oswald Buddenhagen wrote: > i don't like the "either", as it implies XOR, which is contradicted a > moment later. how about this: > >>>Return an extended exit code: Add 32 or 64 to the code if any >>>modifications were made on the far or near side, respectively; >>>these are no

Re: ext-exit documentation

2022-07-01 Thread Oswald Buddenhagen
On Fri, Jul 01, 2022 at 12:35:47PM +0200, Yuri D'Elia wrote: I would still consider, if possible, to include a way to distinguish between temporary errors (all network errors) and hard errors. yeah, i've been pondering this, and i'm somewhat undecided how to go about it. the problem is that the

Crash during synchronization

2022-07-01 Thread Yuri D'Elia
Using the sources on the current main branch: | | Logging in... | Opening far side box INBOX... | Opening near side box INBOX... | Loading near side box... | near side: 318 messages, 0 recent | Loading far side box... | far side: 462 messages, 0 recent | Synchronizing... | Socket error on (:993)

Re: ext-exit documentation

2022-07-01 Thread Oswald Buddenhagen
On Fri, Jul 01, 2022 at 11:48:04AM +0200, Yuri D'Elia wrote: One tab too much. oops "Add either 32 or 64 to the code if any modifications were made [...] i don't like the "either", as it implies XOR, which is contradicted a moment later. how about this: Return an extended exit code: Add

Re: ext-exit documentation

2022-07-01 Thread Yuri D'Elia
On Fri, Jul 01 2022, Yuri D'Elia wrote: > Just trying out the current main branch to play with the current version > of the --ext-exit option :). Thanks for considering this, it's quite > convenient to trigger local hooks. I would still consider, if possible, to include a way to distinguish betwee

ext-exit documentation

2022-07-01 Thread Yuri D'Elia
Just trying out the current main branch to play with the current version of the --ext-exit option :). Thanks for considering this, it's quite convenient to trigger local hooks. The cli help looks fine in the source, but it's shifted when run: -y, --dry-run do not actually modify anythin