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
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
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
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.
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
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
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 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
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
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 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 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
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
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
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
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
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
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)
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
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
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
21 matches
Mail list logo