GNOME Bugzilla – Bug 223621
Add per-account mail Archive Folder option
Last modified: 2016-05-01 10:35:34 UTC
I suggest that a "Archive" local mail folder
and "Archive" selection is added along with
the existing options in the popup menu that
is available in the message index:
"Move to Folder"
"Copy to Folder"
So if the user select "Archive", she should
expect it to end up in a default local mail
folder for saved messages (for example
"Archive") or a user-defined folder (simular
to the "Draft" and "Sent" folders).
This functionality would make neophytes feel
What I would like to see even more than this would be to have
Pine-like mailbox archiving. Set up a task to run every month ( or
however often the user wants it ) to archive the selected mailboxes.
Currently I have cron doing this job - which is fine for me but not
for the non technical audience out there.
Workaround: You could use a filter, activated on a folder whenever you
select Ctrl-A Ctrl-Y, to "move all mail older than 1 month ago to
folder F," although it wouldn't necessarily sort it to individual folders.
It'd be nice to have some sort of archive script, and shouldn't be
that difficult to add: Add an item in the mailer prefs for Archiving,
which chooses a directory (local or remote) and a date. Then, all the
mail past that date will get periodically moved to the archive tree,
which replicates the current-mail tree.
Marking "Future" and changing OS to reflect that it's on all OS's.
*** bug 233704 has been marked as a duplicate of this bug. ***
Iffy dupe. My bug would have all folders compressed when not in use,
but whatever - it also is a 'future, but wouldn't be too hard (given
knowledge of codebase)' bug.
As directed by the hackers mailing list, adding my $.02 to this.
I recall one clear detail from my OS courses. It costs many cpu
cycles to read one block of data off of the hard drive. I do not
know how many in todays ratios, but for the sake of argument, I
think it is still a safe bet that to decompress and compress data is
faster than to load uncompressed data off of a hard drive.
That said, there stands to be some efficiency tradeoffs. I've used
mutt for years now, with the compression option. It works, however
it is more or less a hack. Before opening a file ending in '.gz' or
'.bz2', mutt decompresses it to a temporary working directory, and
then re-compresses it back when finished. This works ok, but when
you have a single mbox file that is 480mb ending in .bz2, and a
decompression time of many minutes on a fast cpu, you begin to
realize there must be a better way.
While I now understand (after reading the archival description
above) the concept of archival, I have yet to understand how it
would work for me. I want to view all emails from my wife, for
example, and so long as the vfolder searches can also search the
`archive' then whatever is implemented with this functionality in
mind I am not going to complain.
Personally, I see two feature requests in this bug id. One is
archival, the other is compression. Both related, but distinctly
I personally would love to have an option per mailbox under
preferences per mailbox to choose to compress the mailbox, and also
a choice with regards to the compression mechanism.
I do not know if it would make sense to compress mbox mailboxes, but
perhaps if one understands that it would simply take a long time on
larger mailboxes, then this could be accepable.
I also do not know if it would make sense to compress Maildir
mailboxes, given that the average email message is so small, adding
a gzip header would add negligible space savings.
For the same reason above, I do not know if it would make sense to
compress individual email messages, either in a modified mbox file
format (aka 'From ...' line unmodified, the rest compressed, or a
special attachment type that is a compressed body), or in some other
It seems to me, that the best solution would be to invent a new
mailbox format specifically with compression in mind. I would
personally suggest such a format have a few user-tweakable knobs,
with sane defaults:
- groups of messages are compressed together, the groups are
indexed, similar to zip format, as individual compression
blocks, for `quick' retrieval in large mail boxes
- the message groups could be defined as a threshold of
a number of messages, or a size of messages; for example:
every 100 messages is a group of messages in a single
every time the 100k barrier is broken, a new group of
messages would be started
- the compression mechanism could be specified as:
- bzip2 (1 .. 9)
- gzip (1 .. 9)
- [any others?]
.. with `auto' each compression block would be tested with
each available compression mechanism, to determine the
one that compresses best; while it is true that one tends
to be the winner in general, in some specific cases I've
seen others better, and in some cases I've seen the
compressed output of one pass is further compressable by
a 2nd pass.
Could anyone suggest anything that is wrong with the above thinking?
My intention is to catch up to current development cvs HEAD, and see
what I can do about the new mailbox format.
P.S. One could also, with a new mailbox format, add a layer of
encryption as an optional 2 pass `decompression' mechanism.
I think you're overcomplicating things.
I also think you're wrong about reading a compressed file being
faster, at least on today's hardware.
I'd need to see a benchmark to believe that.
imho, sticking with zlib is the way to go - no sense adding bunches of
compression options, especially since most people will simply stick to
gzip anyway. same goes for compression level. don't bother. just have
a sensible default.
so what the ui should come down to is something as simple as:
or perhaps just:
also, imho, only archive folders should be compressed. I'm not sure if
they should be read-only or not tho, I wouldn't mind having the
ability to removed messages/etc and/or append more - but for the most
part, things shouldn't change - that's the whole point of making it an
compresion definetely shouldn't be offered for non-Archive folders and
I think Archive folders should be compressed. So as far as I'm
concerned with this feature, Archive is the same as Compress :-)
Apologies for any spam... cc'ing usability-maint on all Evolution usability
bugs. Filter on EVO-USABILITY-SPAM to ignore.
I hate to add a "me too" on a feature request, but I require this feature in my
current place of work. Given that I _rarely_ access older emails I don't care
if the archive is compressed or not, only that it is local and frees up storage
space on my IMAP/Exchange account.
Would this be a Camel function? I'd like to dig a bit further to sort this out
Hi there 2002,
Here are my thoughts on this feature:
* It could probably be a plugin.
* When enabled, it would add a button with a configurable name.
* It would have an associated configurable shortcut.
* When activated, it would move selected messages into a folder.
* It would be per account specific so that firstname.lastname@example.org selected messages go to the email@example.com/archive folder and that firstname.lastname@example.org selected messages go to the email@example.com/sort folder (or whichever were configured).
* Bonus points if it lets you configure N different buttons per account.
This would be particularly useful for users who commonly drag folders in to archives for example.
I'd be willing to help out with this feature (although my C sucks) and/or help sponsor it financially, although I don't have a lot of funds to contribute.
PS: This could also fill the equivalent of the gmail "archive" button, which in equivalent evolution terms is the same as "moving" a message from any folder to the "All Mail" folder. (This causes a duplicate, which ultimately gmail translates into an "archive" operation)
Let's do the usual "Archive Folder" option, which means a per-account setting to select the expected Archive folder, then an option in popup or menu Messages->Archive... to move selected messages into the setup folder. No compression, nothing like that (how would you do that with remote accounts anyway). As the On This Computer doesn't have account properties then the settings can be found at Edit->Preferences->Mail Preferences->General tab->Archive Mail section. An issue with virtual folders, when multiple accounts can be selected uses a quick check for the desired account by picking the first selected message and for it the account of the source folder (no recursion involved) to enable/disable the menu option, but in the execution of the action it checks whole selection and if there are set messages from multiple accounts then nothing happens. This is for performance reasons. The default shortcut is Ctrl+Shift+A.
There had been needed changes in both evolution-data-server and evolution. No way for 3.12 due to new translated strings added, though it's the only limitation, the patches as such should work fine there, maybe only with a little backporting foo). The changes are:
Created commit 0914aa0 in eds master (3.13.7+) 
Created commit f6c0c82 in evo master (3.13.7+) 
(In reply to comment #11)
> Let's do the usual "Archive Folder" option, which means a per-account setting
> to select the expected Archive folder, then an option in popup or menu
> Messages->Archive... to move selected messages into the setup folder. No
> compression, nothing like that (how would you do that with remote accounts
> anyway). As the On This Computer doesn't have account properties then the
> settings can be found at Edit->Preferences->Mail Preferences->General
> tab->Archive Mail section. An issue with virtual folders, when multiple
> accounts can be selected uses a quick check for the desired account by picking
> the first selected message and for it the account of the source folder (no
> recursion involved) to enable/disable the menu option, but in the execution of
> the action it checks whole selection and if there are set messages from
> multiple accounts then nothing happens. This is for performance reasons. The
> default shortcut is Ctrl+Shift+A.
> There had been needed changes in both evolution-data-server and evolution. No
> way for 3.12 due to new translated strings added, though it's the only
> limitation, the patches as such should work fine there, maybe only with a
> little backporting foo). The changes are:
> Created commit 0914aa0 in eds master (3.13.7+) 
> Created commit f6c0c82 in evo master (3.13.7+) 
>  https://git.gnome.org/browse/evolution-data-server/commit/?id=0914aa0
>  https://git.gnome.org/browse/evolution/commit/?id=f6c0c82
Very sweet... Looking forward to trying this somehow!
Tried this out with GNOME continuous...
( http://build.gnome.org/#/ )
1) Control-Shift-A is also used by "Create new appointment" and so it doesn't work. I'd recommend Control-Alt-a instead for this archive feature.
2) Even after selecting a message, the archive option still appeared "grayed out" and I wasnt' able to click on it. So it actually doesn't work!
... But I busted out gtk-inspector, and after trying to figure out how it works, I finally found the menu item you added... I found out that the grayed out means "sensitive" property, changed that to True, and was then able to click on it! Unfortunately, it did not move my message. So it still doesn't actually work :(
3) There should be a corresponding menu item on right click for this archive action. There are the corresponding move to folder, and copy to folder. Archive is missing from the right click menu, but not the main Message menu.
Thanks for looking into this, hopefully you can test it, fix issues, and let's get this into Fedora 21!
Actually... A follow up RE: #2... I think this might have been my fault with an account issue... If I added the Main account (On this computer) archive option this worked as intended. So actually, only #1 and #3 look to be issues.
(In reply to comment #14)
> Actually... A follow up RE: #2... I think this might have been my fault with an
> account issue... If I added the Main account (On this computer) archive option
> this worked as intended. So actually, only #1 and #3 look to be issues.
Right, there is only one reason when the option can be insensitive, it's when the account to which the folder belongs doesn't have configured the Archive folder.
(In reply to comment #13)
> Tried this out with GNOME continuous...
> ( http://build.gnome.org/#/ )
> Using gnome-continuous-x86_64-devel-debug-20141021.17.qcow2.gz
> Some issues:
> 1) Control-Shift-A is also used by "Create new appointment" and so it doesn't
> work. I'd recommend Control-Alt-a instead for this archive feature.
Ouch, I overlooked that. I changed the shortcut to Ctrl+Alt+A and removed an icon for this item, because it was quite similar to the other two there:
> 3) There should be a corresponding menu item on right click for this archive
> action. There are the corresponding move to folder, and copy to folder. Archive
> is missing from the right click menu, but not the main Message menu.
I cannot reproduce this for accounts which have set an Archive folder. If the account doesn't have it set, then the menu item is insensitive and thus hidden from the context menu.