-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should afew's MailMover move emails out of Maildir's /new or /tmp subfolders ? #196
Comments
Right, good catch! However, I hesitate in just silently skipping mails. It might still be a valid usecase to move mails from inside the So I think extending I still need to push some changes on top of #189 (will hopefully get to that this weekend), after that, we should work on a patch to fix the behaviour. |
On moving: I would think we have either "no metadata no UID" or "metadata and UID", but I may be wrong. In any case On the hook ( ;) ): I think that pre-new: afew -m; mbsync |
So, I've checked the maildir and mbsync docs, and the upshot is: Whoever moves maildir mail from UIDs in a maildir using the native mbsync format need to be unique. So, if the message has a UID and is being moved somewhere else then the UID has to be removed (so that it will be reassigned one by mbsync). A UID without |
Addition, sorry: To be extra safe, regenerating the name (as MM currently does) is best. Patch coming. |
This looks great, thankyou! |
I use afew as a post-new notmuch hook, after I've synced my mail using mbsync but before my new mail has been read by my MUA. As a result, new mail is still in the /new sub-directory (and indexed as such by notmuch).
This also means that each of those mail's filenames has not yet had any metadata appended, which means that filename doesn't have a colon in it, which means that MailMover's file renaming strategy breaks. The end result is that the UID element of the mail is not stripped out, leading to conflicting UIDs in the destination Maildir.
I have a small patch for this for afew, which limits moves to files in the "/cur" subfolder.
Does that seem the right approach? Or is this something better handled by calling afew at a different point?
The text was updated successfully, but these errors were encountered: