GNOME Bugzilla – Bug 318803
Maildir camel provider incorrectly creates .#evolution physical folders for .cmeta files
Last modified: 2021-05-19 11:56:29 UTC
Please describe the problem: According to 'fejj' on irc.gimp.net, Evolution is not supposed to create physical representations of the internal '.#evolution' URI on the physical mail storage system. However in Maildir accounts, this occurs with trash.cmeta and junk.cmeta files. The problem is that this .#evolution directory shows up in the user interface and cannot be hidden. Steps to reproduce: 1. Delete any /home/username/Maildir/.#evolution directories that exist 2. Delete a file from your Maildir account's Inbox 3. Look at the Trash folder 4. Close evolution 5. open evolution back up and there is now a .#evolution folder in the list of Maildir folders Actual results: Expected results: Does this happen every time? Yes. Other information: Here is a log from "CAMEL_DEBUG=all evolution >& evo.log" that proves that this is occuring.
Created attachment 53433 [details] Debug output that proves that this is occuring.
confirming
actually, I might be wrong... the cmeta files might be saved for a reason. but the .#evolution folder should definitely not show up in the UI
*** Bug 324484 has been marked as a duplicate of this bug. ***
*** Bug 327812 has been marked as a duplicate of this bug. ***
*** Bug 343418 has been marked as a duplicate of this bug. ***
Created attachment 68122 [details] [review] Attempt to patch, needs review I think this trivial patch fixes this problem: in e-d-s source file 'camel-maildir-store.c', function scan_dirs(), we can simply skip the metadata folder name from the while loop, just like we do for ".", "..", "tmp", "cur" and "new" folders. I tested this on my system and it seems to work, but I'm little bit worried that it actually prevents Trash and Junk folders working correctly, so this patch needs some more testing and thinking.
*** Bug 422603 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Created an attachment (id=68122) [edit] > Attempt to patch, needs review > > I think this trivial patch fixes this problem: in e-d-s source file > 'camel-maildir-store.c', function scan_dirs(), we can simply skip the metadata > folder name from the while loop, just like we do for ".", "..", "tmp", "cur" > and "new" folders. > > I tested this on my system and it seems to work, but I'm little bit worried > that it actually prevents Trash and Junk folders working correctly, so this > patch needs some more testing and thinking. > It works for me on x86 and under amd64, but only on the evo side if to take advantage of other client, for example imap this folder it is visible as #evolution. What it for a folder? Trash? Why then to not use this name?! Here there is more capacious problem, https://bugs.gentoo.org/show_bug.cgi?id=193302.
*** Bug 495986 has been marked as a duplicate of this bug. ***
I will take this patch, but I'll keep bug opened to try to not create such folder, but have it as a file in root folder in some time later. I'll commit to trunk and stable.
Committed to trunk. Committed revision 8878. Committed to gnome-2-22. Committed revision 8879.
(In reply to comment #11) > I will take this patch, but I'll keep bug opened to try to not create such > folder, but have it as a file in root folder in some time later. I'll commit to > trunk and stable. > With imap account present #evolution folder.
(In reply to comment #13) > With imap account present #evolution folder. Yes, this patch just prevent to show the offending folder in evolution when you access it via a maildir protocol.
*** Bug 463534 has been marked as a duplicate of this bug. ***
see bug 564406 for MH backend
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.