Previously, the EmailIdentifier key's hash value was sometimes changing
during the execution of the function, so when someone later went to look
up the flags, the hash map was returning NULL. This way we delay
hashing the EmailIdentifier till right before it's used, so its hash
value can't change.
Both these problems stemmed from conversations holding messages from
in-folder and out-of-folder, and that all messages in the search
folder are considered out-of-folder.
The problem was due a timing issue in ClientConnection FSM; it was possible
for the machine to still be in the IDLE or IDLING state when ready to
SYNCHRONIZE. This is due to a timing hole where the server's response to
close IDLE (requested when the APPEND command was sent) didn't return in
time. This closes that timing hole and deals with SYNCHRONIZE occurring
while in IDLING/IDLE.
This is squashed commit (sorry -- we'll get better about maintaining a
clean history in collaborative branches in the future!) of a massive
amount of work from Jim and myself.
* EmailIdentifiers for normal (i.e. not outbox, etc.) emails are the
same regardless of which folder they came from
* New EmailStore interface to manipulate messages that reside in any
folder, without having to care what folders are open
* Relevant places that manipulate emails (e.g. the toolbar) have been
updated to use the new EmailStore interface
* Conversation and ImplConversation have been smooshed together
* Many, many more items and bugfixes related to the above points
We discovered a situation where, depending on the order email is
processed, it's possible for logically associated emails to form
two or more conversations. When an email is processed that belongs
in more than one conversation, its removal triggers this error (as
a Message-ID can be associated with one and only one conversation).
Bogus email headers, especially email that does not list a complete
References: list, aggravate this problem.
Charles discovered that some of the operations in ImapEngine.GenericFolder
were exiting before waiting for the command to complete, meaning the
async call returned while the operation was still running. This
has a broader problem if the command is executed (with a yield) and
then the folder is closed.
Account synchronizer now stops when it recognizes that all the mail in
the folder is present (but perhaps not completely downloaded) from
the server. The email prefetcher takes care of ther rest.
Also discovered a regression from last week's commit that prevented
vector expansion when using find_earliest_email_async(); fixed here
as well.
Encountered this morning -- list operation had unfulfilled emails
waiting for network operations but folder normalization determined
they were missing and used a writebehind to remove them from the
operation, but the loop to remove them explodes (can't do a remove
within a foreach). This loop solves that problem.
Two problems: (a) determination for vector expansion was not accounting
for INCLUDING_ID flag properly, and (b) messages added to the interior of
the vector during normalization (can happen when the database has a
gap in the middle of the vector) were being treated as appended (i.e. new)
messages, causing the ConversationMonitor to load all of them.
Forgot to deal with situation where a message in the remote folder
is removed that isn't stored in the local database. In that case,
the local position will be <= 0 and should be treated as a NOP
(although still signal that the total remote_count has changed).
Rather than attempt to be selective, there's enough changed here that we might as well
blow away the search index and let the indexer start afresh. Future tweaks to the
search index might need to be more selective.
Fixes a couple of performance problems (slow sorting of Contacts
being added one at a time, and multiple GtkEntryCompletions being
created when New Message is used) as well as broke out
ContactListStore so one could be created and used for the three
GtkEntryCompletions needed in the window.
Better document structure handling. Now dealing with all portions of a
MIME document, not just the first, and properly inserting inline images
into the final HTML view.
