mbsync keeps crashing
ok, thanks. the message is clearly zero bytes in size, and i need to harden the code against such garbage.
* 46 FETCH (UID 2432 FLAGS (\Seen)) * 47 FETCH (UID 3784 FLAGS (\Seen)) * 48 FETCH (UID 6005 FLAGS (\Seen)) * 49 FETCH (UID 6146 FLAGS (\Seen)) * 50 FETCH (UID 6147 FLAGS (\Seen)) * 51 FETCH (UID 6980 FLAGS (\Seen)) * 52 FETCH (UID 9897 FLAGS (\Seen)) 25 OK Success far side: 52 messages, 0 recent Synchronizing... >>> 26 UID FETCH 2214 (BODY.PEEK[]) (1 in progress) >>> 27 UID FETCH 2215 (BODY.PEEK[]) (2 in progress) >>> 28 UID FETCH 2218 (BODY.PEEK[]) (3 in progress) >>> 29 UID FETCH 2311 (BODY.PEEK[])...
please post the last lines of output from mbsync -a -Dn.
Can someone please help to fix this issue properly?
Looking at the source code, it seems that in src/drv_imap.c static int parse_imap_list( imap_store_t *ctx, char **sp, parse_list_state_t *sts ) { ... } else if (*s == '{') { /* literal */ bytes = strtoul( s + 1, &s, 10 ); if (*s != '}' || *++s) { sts->err = "malformed literal"; goto bail; } if (bytes >= INT_MAX) { sts->err = "excessively large literal - THIS MIGHT BE AN ATTEMPT TO HACK YOU!"; goto bail; } ... In above, when the bytes is 0, if (!(p = socket_read( &ctx->conn, n, bytes, &n ))) this...
mbsync keeps crashing
Sync fails with Near MaildirStore on XFS filesystems
near side subfolders cannot be opened
point 1 fixed in 8c781d4f, point 2 in 17c9cc11.
fix implicit listing of Maildir INBOX under Path
improve reporting of failure to open previously present mailbox
fix typos
I added INBOX* to patterns, and everything is working again. Thanks
regarding the second point, it's actually behaving correctly, only the error message is confusing: because the folder is absent (or so it thinks), but the state file is there (in a folder it thinks is absent, heh), it concludes that the folder was deleted. this is distinct from the folder never existing, so it won't attempt to create it. and you didn't configure folder deletion propagation (which would also fail due to the other end being non-empty), so it just complains. i'll try to make the message...
near side subfolders cannot be opened
ok, thanks. at least two things are going wrong here: - INBOX and its subfolders are not listed for the local stores. this is because of commit acd6b4b, which has a bogus rationale. you can work around it by adding INBOX* to Patterns. - it doesn't try to create the seemingly missing boxes even though you configured that. or it tries, but the error handling is misleading.
the use of an isync/ subfolder was discussed on the list. i didn't want that pointless clutter. i'm also not sure what relevance that has for your problem, as storing the mail under .config/ would be patently wrong anyway. just use absolute paths starting with ~/ and be done with it. i have no idea from what package your maildir manpage is, but it has no authority whatsoever. isync doesn't know anything about $MAILDIR. please use the list to discuss problems with your configuration.
It now uses $XDG_CONFIG_HOME/isyncrc. A more customary location would be $XDG_CONFIG_HOME/isync/config rather than$XDG_CONFIG_HOME/isyncrc or $XDG_CONFIG_HOME/isync/mbsyncrc. Having a separate directory is especially a good idea since for some reason, relative paths are interpreted from the directory containing the config file rather than ${MAILDIR-${HOME}/Mail} (I've been working on an MR to change the base path for relative paths, but I'm sure it'll get rejected even if I get it working correctly...
I sent the addl mbsync output and complete config via email. lmk if there's anything else I can provide to debug.
Update spec file
Fix Fedora 40 crash caused by LTO
I.e. this can be closed.
OK it does fix the issue. I tested it! I report this to the Fedora bug, thank you.
weird, i can't see anything obviously wrong. try mbsync -l -a -D for good measure, and attach/mail the complete config.
sent via email
the change doesn't affect you. for starters, try mbsync -ls -D and attach the output (or mail it privately).
near side subfolders cannot be opened
i think this is already properly fixed by commit ceb0fa980.
Unable to build successfully due to recent commits
fixed by commit 4c2031d6.
Right you can add patch per comment. Well here's v2.
One remark. Now that I re-tested my patch I had to: -mbsync_CFLAGS = -fno-lto +CFLAGS += -fno-lto Otherwise: drv_proxy.c:458:10: fatal error: drv_proxy.inc: No such file or directory 458 | #include "drv_proxy.inc" | ^~~~~~~~~~~~~~~ I don't understand this causality so not updating patch yet.
For more information, see the discussion at https://bugzilla.redhat.com/show_bug.cgi?id=2302132 When LTO is on boxes array is literally truncated to a single element array. I do not think mbsync will have any particular benefit from LTO so it would really be pragmatic decision to plain disable it also to prevent any future issues happening.
For more information, see the discussion at https://bugzilla.redhat.com/show_bug.cgi?id=2302132 When LTO is on boxes array is literally truncated to a single element array.
For more information, see the discussion at https://bugzilla.redhat.com/show_bug.cgi?id=2302132
Fix Fedora 40 crash caused by LTO
add missing trailing newlines in error() calls
fix IMAP INBOX case normalization
fix initial build from git
Unable to build successfully due to recent commits
... and additionally, i broke the git bootstrap. heh.
Unable to build successfully due to recent commits
do downstream packagers have to adapt to conform yes, if they use git archives instead of tar balls or plain git clones.
Unable to build successfully due to recent commits
generalize AUTHORS section of man page
substitute version and date in man pages
automate setting package version
Assertion failure in IMAP driver
fixed in master in commit 8b83139.
in case of error, isync tries to create already existing boxes
fixed in master in commit 84194a7a.
generalize GPL exception
update some email addresses
add tag files to .gitignore
revamp automatic enumeration of power-of-two enumerators
remove redundant argument from BIT_FORMATTER_PROTO()
eliminate commit_cmds driver callback
Revert "actually implement imap_commit_cmds()"
don't try to create already existing boxes
don't try to qsort() NULL array
cap readsz at buffer size
Subfolders style required when for subfolders in hidden folders, despite use of `Flatten`
would not add value, as per previous discussion.
is 163.com still misbehaving this way?
did you try the LARGEFILE thing? did it work?
Socket error on localhost (127.0.0.1:1144): timeout. F: Callback leave bad store
no info forthcoming.
Gracefully handle unexpected EOFs with OpenSSL 3.0?
fixed in commit b6c36624.
IMAP command 'UID FET)' returned an error
ok, closing this as an external issue.
Unexpected tags interrupt sync when talking to outlook.com's IMAP servers
I added the ability to supply credentials through stdin.
not needed.
Remove use of getpass
please re-open in case this becomes serious one day.
but how would that help? without some background info this is just confusing. the user finding out through isync's complaint is equivalent to that. you already wrote that you fixed it that way. the question is how that "fix" fits into the bigger picture of the configuration.
I was able to fix it with the following configuration (add subfolder style to the store): MaildirStore personal-local Path ~/Maildir/personal/ Inbox ~/Maildir/personal/Inbox Flatten . Subfolders Verbatim All I propose is that we update the documentation, from this: SubFolders Verbatim|Maildir++|Legacy The on-disk folder naming style used for hierarchical mailboxes. This option has no effect when Flatten is used. To this: SubFolders Verbatim|Maildir++|Legacy The on-disk folder naming style used for...
the question is then what happens next. i don't think real subfolders will be liked particularly well in an otherwise flattened hierarchy. i suppose an exclusion pattern or not using patterns in the first place works, but it's kinda dirty. (how) did you get it running?
Ah, I see, thanks for clearing up my confusion. It seems there is no restriction on naming convention for IMAP folders on dot character for hidden files, so technically mbsync should look there, and I was mistaken about hidden folders. However, it still seems strange to me that it tries to look in a subdirectory for a Maildir that is using Flatten. It would have been clearer to me if the documentation specified that mbsync would look in subdirectories despite setting Flatten (even when it doesn't...
you're making some rather unfounded assumptions. the documentation is actually entirely correct, when nothing external messes with the maildir structure. but of course it needs to know what to do with weird folders that appeared out of nowhere. dot files being hidden is just a convention, not something set in stone. and the nested maildirs clearly kinda disagree. it would be rather negligent to just ignore these folders.
Subfolders style required when for subfolders in hidden folders, despite use of `Flatten`
Ok. Eitherways, thanks for your answer
i'm not convinced. the deprecation is kind of bogus, and there is roughly zero chance that it will be followed through. "easier integration with scripts" is a non-feature. you can just use PassCmd /bin/cat if you want something this fragile. but you should use PassCmd properly instead.
Remove use of getpass
q not suppressing notice
yeah. i'm a bit undecided which way it should go. the thing is that these messages really are warnings, as things will break ... but only at some point in the future.
Here is my diff file with the fixes.
Looking over the code base a bit more, it's the same thing for a few other things: src/main.c:742 warn( "Notice: -master/-slave/m/s suffixes are deprecated; use -far/-near/f/n instead.\n" ); src/drv_imap.c:3724 warn( "Notice: %s '%s': UseSSL*, UseTLS*, UseIMAPS, and RequireSSL are deprecated. Use SSLType and SSLVersions instead.\n", type, name ); src/drv_imap.c:3737 warn( "Notice: %s '%s': 'RequireSSL no' is being ignored\n", type, name ); src/drv_imap.c: 3758warn( "Notice: %s '%s': RequireCRAM is...
q not suppressing notice
thanks for testing. this looks about right.
After git apply 0001-don-t-try-to-create-already-existing-boxes.patch in e70c300f7446ba6ec1259f459a0f0e1d2d592ed9, I try to mbsync -aD, then Connecting to imap.yeah.net ([2407:ae80:100:1000:123:58:178:176]:993)... Connection is now encrypted F: * OK Coremail System IMap Server Ready(yeah[462f053f8e52ea4f04a77e3568be9a49]) F: >>> 1 CAPABILITY F: * CAPABILITY IMAP4rev1 XLIST SPECIAL-USE ID LITERAL+ STARTTLS APPENDLIMIT=71680000 XAPPLEPUSHSERVICE UIDPLUS X-CM-EXT-1 SASL-IR AUTH=XOAUTH2 F: 1 OK CAPABILITY...
However, I believe that implementing this feature could greatly benefit users facing similar challenges without compromising the project's integrity. Given the significant user base and the widespread use of NetEase services, accommodating their requirements becomes essential for ensuring compatibility and user satisfaction. While it's not ideal to have to adjust for such specific demands, doing so can help maintain a seamless experience for a large number of users. To address this, I propose adding...
I completely agree with your perspective. This security check is nonsense.
i can implement that, but the RFC states rather plainly that the server must not make operation dependent on it. it is blatantly and intentionally violating the standard.
https://github.com/OfflineIMAP/offlineimap3/issues/71