GNOME Bugzilla – Bug 732145
Breaks existing (not evolution's) maildir folder structure
Last modified: 2015-04-23 05:05:37 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1112331 Description of problem: I use mbsync to keep a local maildir copy of my email account. I usually handle it with mu4e or mutt but I tried to configure it also for evolution. When I added my maildir folder to evolution accounts if loaded correctly all my emails, but when I closed it I noticed that my local maildir folder was completely broken. The initial folder structure was the following: 1) all the first level folder where present into my ~/Mail folder 2) all the subfolder where present into the parent folder with a dot prepended. Example: INBOX Archive -> work Sent ~/Mail/INBOX ~/Mail/Archive ~/Mail/Archive/.work ~/Mail/Sent After runing evolution the structure was the following: 1) all the first level folder where present into my ~/Mail folder with a dot prepended 2) all the subfolder where present into my ~/Mail folder with the parent folder prepended and also a "_2E" as a path separator. 3) all ma previous folder were left ~/Mail/INBOX ~/Mail/Archive ~/Mail/.Archive ~/Mail/Archive/.work ~/Mail/.Archive_2Ework ~/Mail/Sent ~/Mail/.Sent Version-Release number of selected component (if applicable): evolution-3.10.4-2.fc20.x86_64 How reproducible: The issue if fully reproducible, just redowload your emails and add them back to evolution. Steps to Reproduce: 1. configure a local mail sync with mbsync (or offlineimap) 2. load that folder with evolution 3. close evlution and inspect the content of the maildir
Confirmed. Now for downloading all this mail again …
Sounds like a perfect example of where it's a good idea to let dovecot handle the mail folders instead of Evolution directly. Just configure it with an IMAP+ back end; instead of making a network connection to a server, it's simple to just configure it to run a command like '/usr/libexec/dovecot/imap' instead.
I guess the problem is that Evolution screws up user files upon simply *opening* the program, without her consent. That should *never ever* happen. Niemals, jamais, 努. And it’s certainly not the fault of the user.
It seems that Evolution even screws up the folders it has created itself. If I create a new Maildir and point evolution at it I end up with: $ ls -A ..cmeta cur/ ..ibex.index ..ibex.index.data new/ tmp/ If I then create a subfolder TEST of the inbox I get: $ ls -A ..cmeta cur/ ..ibex.index ..ibex.index.data new/ ..TEST/ ..TEST.cmeta ..TEST.ibex.index ..TEST.ibex.index.data tmp/ and the GUI shows TEST as a subfolder of Inbox. If I then restart evolution it rewrites the folder to: $ ls -A ._2E_2ETEST/ ._2E_2ETEST.cmeta ._2E_2ETEST.ibex.index ._2E_2ETEST.ibex.index.data ..cmeta cur/ ..ibex.index ..ibex.index.data new/ tmp/ and I now see "..TEST" as a top-level folder in the GUI. After another restart I get: $ ls -A ._2E_5F2E_5F2ETEST/ ._2E_5F2E_5F2ETEST.cmeta ._2E_5F2E_5F2ETEST.ibex.index ._2E_5F2E_5F2ETEST.ibex.index.data ..cmeta cur/ ..ibex.index ..ibex.index.data new/ tmp/ and the paths just keep growing with each restart. I'm running evolution 3.12.9~git20141130.241663-1+b from Debian. e-d-s is 3.12.9~git20141128.5242b0-2+b1.
I saw this in another bug report too, or a mailing list. The problem is that evolution-data-server's Maildir provider tries to "migrate" folders with dots when there is no ".maildir++" file. There was some issue to create it, but I didn't find out what it was. Nonetheless, the file could be created by a user and when it was populated with a string: "maildir++ 1" (quotes for clarity only), then the Maildir provider stopped to break the folder structure. I'll try harder to reproduce this.
Hi Milan, Are you saying that: echo "maildir++ 1" > $MAILDIR/.maildir++ should work around the issue? In Comment #2 David said "instead of making a network connection to a server, it's simple to just configure it to run a command like '/usr/libexec/dovecot/imap' instead." and I remember such an option in the past, but it seems to have gone, at least from the GUI. Is it still available internally somehow or is it completeley gone?
I tried the echo and it didn't help.
(In reply to comment #6) > Hi Milan, > > Are you saying that: > echo "maildir++ 1" > $MAILDIR/.maildir++ > should work around the issue? Yes, I'm saying that, but my fault, the name of the file is different. Simply copy the file ~/.local/share/evolution/mail/local/..maildir++ to your $MAILDIR (there are double-dots as a prefix, not a single dot as I said above). > In Comment #2 David said "instead of making a network connection to a server, > it's simple to just configure it to run a command like > '/usr/libexec/dovecot/imap' instead." and I remember such an option in the > past, but it seems to have gone, at least from the GUI. Is it still available > internally somehow or is it completeley gone? It's removed only from GUI, but the imapx backend is still capable of it, if it was compiled with a new-enough GLib (I think it was 2.40.0+). Locate the right file at ~/.config/evolution/sources/ you can find it by a host name or such. It should have an [Imapx Backend], where you can find a ShellCommand key with prefilled "ssh -C -l %u %h exec /usr/sbin/imapd". Change the value to the right one and set also UseShellCommand=true. Then save the file. Ideally do this file change with evolution-source-registry down, which is not always possible(for example with gnome-shell). The UI might get back one day eventually, but that's out of scope of this Maildir bug.
"mv .maildir++ ..maildir++" does appear to have workaround the issue, thanks! I'm only using a throwaway maildir right now and I'm about to go away for ~10 days, but when I get back I'll try and combine offlineimap with Evolution maildir and see how I get on... Thanks for the info on UseShellCommand, with the maildir stuff now working I suspect I won't need it, but useful nonetheless. Cheers, Ian.
I managed to reproduce this, the problem was that there was an attempt to rename file "." (which is a folder) to a different name during migration, which resulted in a set GError, which was later used to g_file_set_contents() call, which fails due to a constraint of not passing non-NULL *error into it. It even didn't try to create the file due to this check. I fixed it, but I also agree that Evolution (Camel) should not touch Maildir structure which is not its, thus I made more changes and the dot escaping (which is used to be able to create folders containing dots) is done automatically only for private evolution folders (under ~/.local/share/evolution/mail/). I believe that some users might need to create folders containing a dot also out of this user folder, thus the code is smart enough to turn on the dot escaping when the root Maildir structure folder already contains the "..maildir++" file. It can contain anything at the beginning, the Camel will take care of the right value and migration on its own once it's there. I also changed order in which the migration is done, in a way that the "..maildir++" file is populated first and only then the dot escaping is done, thus if the file creation fails for whatever reason there is not migrated anything, neither the migration can be run multiple times when the file creation fails. Created commit f3094bd in eds master (3.13.90+) [1] Created commit c8b968c in eds evolution-data-server-3-12 (3.12.11+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=f3094bd
*** Bug 727364 has been marked as a duplicate of this bug. ***