Hi,
Oswald Buddenhagen <oswald.buddenha...@gmx.de> writes:
> On Thu, Jun 10, 2021 at 12:14:55PM +0200, Nacho Barrientos wrote:
>>Hi again,
>>
> ah, there, arrived just when i was replying. ^^
Yeah, sorry, there's some inconvenient lag processing the mailing list
messages apparently :/
Yes, I had already used gdb to locate the offending buffers. Not sure
the patch made it to the mailing list as an attachment though so here it
is:
From 386f1e5037d88ade03f299c68d622b0179b07657 Mon Sep 17 00:00:00 2001
From: Nacho Barrientos <nacho.barrien...@cern.ch>
Date: Thu, 10 Jun 2021 12:12:00 +0200
Subject: [PATCH] Allow bigger IMAP messages
---
src/drv_imap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/drv_imap.c b/src/drv_imap.c
index 3c85c4d..d062f1f 100644
--- a/src/drv_imap.c
+++ b/src/drv_imap.c
@@ -339,7 +339,7 @@ send_imap_cmd( imap_store_t *ctx, imap_cmd_t *cmd )
int bufl;
const char *buffmt;
conn_iovec_t iov[3];
- char buf[4096];
+ char buf[4096*2];
cmd->tag = ++ctx->nexttag;
if (!cmd->param.data) {
@@ -512,7 +512,7 @@ imap_vprintf( const char *fmt, va_list ap )
const char *s;
char *d, *ed;
char c;
- char buf[4096];
+ char buf[4096*2];
d = buf;
ed = d + sizeof(buf);
--
2.32.0
>
>>Big kerberos tickets on our side I guess :)
>>
> yeah, seems plausible. searching "kerberos token bloat" produces some
> scary results. the question is what a sensible upper limit would be. i
> can make it quite huge without major detriment.
If you're happy to just double the sizes as suggested above please go
for it, otherwise I can get finer numbers based on my use case if I
manage to find the time to do it.
Thanks again so much!
--
bye
Nacho
http://cern.ch/nacho
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
