Activity for Oswald Buddenhagen
-
Oswald Buddenhagen modified ticket #87
Failing to fetch complete mailbox from Yahoo!
-
the culprit is the server returning partial fetch responses, which are tagged with [LIMIT] . this obviously completely derails isync. yahoo is attempting to standardize (a slightly more advanced version of) this behavior in rfc9738. to cite from this awesome document: If the server has a MESSAGELIMIT of 1000, the client will only be able to download 1000 of the most recent messages; the client will not understand why, will not be prepared to recover from the situation, and will act as if it is interacting...
-
this sounds bad. it seems that it thinks that the downloads were completed, so it treats the missing mails as deletions. and it somehow fails to see 70k+ messages. to debug this, i need the full log (with -D) of both the initial sync attempt and the destructive followup. that means that you need to start from scratch locally. do the second run with --dry-run, which should be good enough without causing actual damage. you can mail me the logs in private.
-
Failing to fetch complete mailbox from Yahoo!
-
which coding agent exactly was that? the patch looks about correct, except that the actual ID string is mildly stupid. i'll have to check the spec for the correct fields and command order.
-
add support for imap id extension
-
so it appears that the various netease domains weren't fixed ....
-
make imap_msgs test actually return non-zero on failure
-
clarify that maildir message moves should preserve the flag field
-
mention that plain --debug excludes driver-all as well
-
fix conditional on undefined value on some config syntax errors
-
fix crash in mkdir_p() with invalid path
-
the "filtering" is actually excessive noise reduction applied by the camera driver. on my redmi 11t pro, one can disable that in OC's image processing options. interestingly enough, there appears no way to disable it in the stock camera app, presumably because xiaomi wants to paper over just how noisy the cameras are. for the macro camera thing, see ticket #1058 (and many others). i recommend closing this ticket.
-
i think it would be reasonable to enable the user to manually pre-configure the cameras. a wizard that tries different things (and commits the state prior to each test, so it could resume after app/device crash). from this you could even build a device database mostly automatically, based on users allowing the app to submit the resultant config. i'm using a custom rom on a xiaomi phone that already went out of support. i don't think betting on proper support by the manufacturer will get us anywhere....
-
please attach (or mail me) your config file and the logs of both runs, but with the -D option added. make sure that each run would actually have something to upgrade.
-
you may want to give the wip/includecmd branch a shot.
-
Add IncludeCmd directive to config parser
-
Refactor printing configuration errors
-
add support for single-quoting to our printf implementation
-
add unit test for our printf implementation
-
make imap_msgs test actually return non-zero on failure
-
Add IncludeCmd directive to config parser
-
Add IncludeCmd directive to config parser
-
Refactor printing configuration errors
-
fix conditional on undefined value on some config syntax errors
-
the warning suggests that you have a literal "INBOX" folder in your maildir, next to the "Inbox" you actually want. you should delete it after making sure there is nothing worthwhile in it. the error is more mystifying, as this shouldn't be even possible with MapInbox. that might be a genuine bug. however, your summary line says 4 boxes, while your pattern specifies only 3, so something is inconsistent here.
-
you should cut it down to what is actually needed. if some weirdness persists at this point, we can investigate.
-
possible test failures (linux)
-
make check does indeed run only the unit tests, while the integration test needs to be run manually. this has historical reasons, but given how slow the latter is, i am hesitant to change things. the test expects to be run from within the src directory with ./run-tests.pl.
-
release preparation
-
expand NEWS
-
stub out ChangeLog
-
--quiet is not suppressing some notices
-
Dry run results in duplicate emails
-
Path cannot be nested under Inbox
-
as there were no further followups, i'm assuming that the configuration issue was resolved. i had a quick look at the code checking that Path is configured, and found that it should be triggered only if Path is actually referenced somehow, f.ex. via a Pattern. so i'm assuming that this issue was part of the bigger misconfiguration. please post a minimal reproducer if that is incorrect.
-
the results of mbsync -ls -D before updating my .mbsyncrc: isync 1.5.0 called with: '-ls' '-D' Reading configuration file /home/mochan/.mbsyncrc merge ops (in Channel 'icf'): common: OP_NEW,OP_OLD,OP_UPGRADE,OP_GONE,OP_FLAGS,OP_EXPUNGE far: XOP_HAVE_TYPE,XOP_HAVE_EXPUNGE,XOP_HAVE_CREATE near: OP_CREATE => far: OP_NEW,OP_OLD,OP_UPGRADE,OP_GONE,OP_FLAGS,OP_EXPUNGE,XOP_HAVE_TYPE,XOP_HAVE_EXPUNGE,XOP_HAVE_CREATE => near: OP_NEW,OP_OLD,OP_UPGRADE,OP_GONE,OP_FLAGS,OP_EXPUNGE,OP_CREATE merge ops (in global...
-
Hi, Thanks for your answer. I configured my mbsync more than a decade ago, so you're right that I don't actually understand what Inbox and INBOX are or ought to be. In my local machine I have a ~/Maildir/ directory with its usual cur/ new/ tmp/ subdirectories, and that is my actual inbox, where I receive nuew mail. Furthermore, I have many subdirectories, such as mbox, mbox2023, mbox2023... where I write emails I have already processed. In my configuration I have a couple of channels to either synchronice...
-
prefix deprecation notices with file name
-
presumably, commit 1e0b661d in master fixes this.
-
the mapping looks just fine, no? that it wants to both push and pull is a classic indication that no sync state is present (or has been found, in your case). testing this with dummy accounts seems rather pointless, as that will just sync from scratch anyway. then you can just throw away your maildirs and sync state, and start afresh. so just move the sync state files in place and try with -y (preferably after you install git master). cp -al the local store somewhere, just in case.
-
whoops, yeah, it obviously should be Near :emlocal:INBOX/. yes, you can (and should) delete the bogus folders. as you're not using SyncState *, you should also clean out corresponding state files from the sync state directory. ah, the SyncState thing is also why it wants to fetch the inbox from scratch - the logical folder names changed, so the state file names don't match anymore. you can simply rename them to match (considering that / is translated to !), but i would recommend that you actually...
-
well, the dots on the server are just directories as far as isync is concerned, provided the server tells it so according to spec. just try the new config with -l. if it's still wrong, you need to look at your paths and -ls output again. if you can't make sense of it, attach the outputs and the updated config.
-
i believe the -ls hang and the ineffective --dry-run to be now fixed in git master.
-
fix -ls hanging after synchronous error
-
fix --dry-run without --debug-driver
-
oh, right, now that you mention it, it's totally obvious: the "drying" is implemented in the proxy driver which implements -Dd. fix upcoming ...
-
but did it actually copy anything? the dry run is intentionally very thorough in pretending that it does something. adding -Dd will show what is actually happening.
-
you probably need something like Channel em Far :em: Near :emlocal:INBOX. Patterns mbox% ... Channel emInbox Far :em: Near :emlocal: Group ems Channels em emInbox hmm, indeed, Path cannot be omitted with SubFolders Verbatim. that's actually kinda a bug. just set it to something useless like ~/tmp.
-
ok, thanks. looks like i just failed to wire up the error cleanup path callbacks properly.
-
yeah, that config won't work anymore, because it's incoherent. however, you can adjust the config to actually match the physical layout. you only need to make it more similar to the other store: unset Path and MapInbox, set Inbox ~/Maildir, and SubFolders Verbatim. then adjust the Patterns to the resulting new layout. make sure to test with -ls and -l before you run an actual sync, as otherwise you'll get duplicate boxes if something doesn't match. the hang is definitely a bug, so keep a copy of...
-
first you should make sure that you actually understand what Inbox and INBOX are. then you can assess how this relates to your actual setup, and from there determine how to fix or simply suppress the problem. you probably also shouldn't be using MapInbox. useful diagnostic steps are running mbsync -ls and later mbsync -l -a, but that might require at least suppressing the issue at first. if you need further assistance, attach your config and the output of the first command.
-
explicitly strip newline from contents of VERSION
-
Update https://isync.sourceforge.io/mbsync.html
-
build: also consider builds off of git with `git clone --depth 1`
-
build: also consider builds off of git with `git clone --depth 1`
-
Large Maildir Synced fast for first 78% of ~600k message, now at snails pace one per email for rest
-
ok, thanks for the update.
-
mbsync keeps crashing
-
accept zero-sized messages from IMAP
-
it's somewhat surprising that your hack doesn't crash later on. please try this updated patch.
-
did you review it only, or did you test it with a box that causes a crash without it? i didn't test it, as i don't have a suitably broken mail server set up currently.
-
so the upshot from what i remember: - please clean up the branch (squash, etc.) - use sensible committer info - the packager line is only there to distinguish it from "proper" rpms, and i don't really care i'll re-review it properly when i see an update.
-
huh, crap, this effin' system didn't actually post my comments, and now the draft is gone. :-(
-
ping!?
-
[PATCH] add(mbsync-get-cert): support STARTTLS and custom port
-
Unsafe login with 163 emails
-
due to lack of followup i'm assuming that this has become a non-issue.
-
can you check whether the attached patch is sufficient to produce a sensible result?
-
Large Maildir Synced fast for first 78% of ~600k message, now at snails pace one per email for rest
-
Segmentation fault from referencing NULL srec->msg
-
mbsync-get-cert: add support for STARTTLS
-
make summary more concise
-
fix crash when resuming message propagation with MaxMessages
-
fix omissions in making expiration target side configurable
-
do not let both-sided uidvalidity change deter us
-
it looks a bit hacky at first sight, but the pointers being null is actually legit. will commit as-is.
-
Segmentation fault from referencing NULL srec->msg
-
it looks like the problem is triggered by a server-side message having disappeared after a transaction to propagate it was started and then interrupted. copying the null check from line 1214 is presumably an adequate fix, but i still need to consider the bigger picture, e.g. if pulling it ahead would be appropriate. and come up with an autotest.
-
i'm aware of one other person using it, in a way it really was not intended. but the code is actually rather heavily auto-tested, so nothing to worry about per se. in fact, if you managed to add a failing case to run-tests.pl, that would be ideal, though this is obviously a somewhat tall order.
-
oh, wow, somebody is apparently actually using MaxMessages. :-o the crash is obviously due to srec->msg[xt^1] being null, but i don't know why that is the case. please add -D to the command line and attach the log (or mail it to me privately).
-
*** socket debug
-
*** shrink buffer
-
Unable to retrieve inbox mail from Yahoo Mail
-
excellent!
-
well, yes, that commit does seem very pertinent. so do you see a difference between 1.5.0 and git master?
-
duplicates may come exactly from the "lost" messages. though it seems to be quite many. alternatively, you'd get dupes if you deleted the sync state without deleting the box. you can find dupes by opening the box directly with mutt (on the server, or via imap) and tagging the pattern ~=, iirc. your configuration seems just fine. the use of Patterns seems pointless, but not problematic. you should probably re-read the manual, as you seem confused about some things.
-
are you sure you aren't hitting some configured server limits? or that the server isn't thrashing? in principle, you could be hitting limits even when just re-syncing old messages, as retrieving such huge message lists alone causes quite some traffic. experiment some with partial syncs, e.g. --push-new. next, inspect the traffic itself, looking at -Dn output. do you see a pattern across multiple runs? next you could also inspect the low-level traffic using wireshark, but if something turns out odd...
-
remove stray closing brace from man page
-
remove stray closing brace from man page
-
mbsync-get-cert: add support for STARTTLS
-
mbsync keeps crashing
-
ok, thanks. the message is clearly zero bytes in size, and i need to harden the code against such garbage.
-
please post the last lines of output from mbsync -a -Dn.
-
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
1 >