that are to be deleted locally as that is much quicker.
Bo, there is code in findByUID() which effectively rebuilds the uidMap
for each message that is not on the server anymore to make sure it has not
_not_ found it locally due to a problem with the map. Is that kind of
paranoia really necessary? What are the chances of that datastructure
being invalidated in between the mail listing and the use of findByUID()?
svn path=/trunk/kdepim/; revision=297966
This makes sure that during a cache trouble shooting the following does not
happen:
- sync the folder as normal
- last uid is set to the last uid correctly
- cache is written
- trigger troubleshoot
- uid validity is set to INVALID
- writeUidCache() is called to reset the cache
- that returns immediately leaving the uidcache untouched
- getting messages writes the new (correct) uidcache value only after each
mail has been added to the folder and with a one minute timeout
- KMail crashes during that time (see my other commit of today)
- the next sync uses a stale uidcache file, finds mails it gets not in
the local cache but with a known ( <=lastUid() ) uid and deletes them
from the server
This seems like a reliable way to nuke your inbox and it's happened to me
today.
svn path=/trunk/kdepim/; revision=292522
o Enable the expiry settings in the folder properties for imap and dimap
folders.
o Add some folderjob infrastructure to imapjob and cachedimapjob along the
way.
o Fix a few folderstorage crashes waiting to happen.
Only manual expiry of imap/dimap folders is hooked in, but we could just
as well hook the imap and dimap foldermanagers into the autoexpiry on
shutdown thingie. For dimap that should be as safe or unsafe as for maildir
and for imap it's as save or unsafe as deleting a bunch of messages and
immediately closing KMail. Opinions?
This commit is dedicated to the hardest working man in show business,
S. Kulow whose birthday it is today.
Let's give it up for the man:
o/` For he's a jolly good RD, for he's a jolly good RD, for he's a jolly
good RD ... which nobody can't deny .. o|`
CCMAIL: 48189-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=290404
o remove duplicate in KMFolderCachedImap
o use the one from KMFolderImap everywhere
o add const to parameters as we go
Rinse, lather, repeat.
svn path=/trunk/kdepim/; revision=289324
o move a bunch of places from KMMessage to KMMsgBase, we no longer need to
look at the whole message
o if the server supports the uidplus extension, listen when it tells us the
uid of an uploaded message and set the msg uid to that, thereby avoiding
redownload of the mail we just uploaded
Together that speeds up dimap by a factor of 10 to 20, according to trust-
worthy sources.
svn path=/trunk/kdepim/; revision=289295
- We used to give a list of pointers of messages to upload to the server,
which is really bad, since the user could delete one before the job would
get around to upload it. Now it works on serial numbers instead and
there are no more crashes in this area
- We had two QDicts: IMAP UID -> KMail index and index -> UID. This was
not good because the maps would get out of sync and result in rebuilding
way too many times, plus the map from index to UID was not necessary.
Now the redundant map is gone, and a dirty flag was introduced to only
rebuild when necessary. This was one of the more serious reasons we
had dIMAP do 100% cpu time because it ended up in a very time consuming
O(n^2) remap method
- For stability reasons, we need to save the highest UID number we have
downloaded from the server fairly often. We took this seriously and
saved on every message. Another of the reasons it was incredibly slow.
Now it's timed, so there will only be a save a minute
- Don't write a uid cache file when we don't have any info for it
- Delete the uid cache file from the dimap cache directory
- Don't rebuild the remaining uid map all the time
- Fix bug 68587 - delete the relevant folders from the folder tree when
the account is removed
Patch reviewed by Till.
Bo.
svn path=/trunk/kdepim/; revision=276112
active readerwindow to ask that for the attachmentstrategy but pass it
along with the folder job, so it is available when the mime structure
comes in with load on demand. Remove unused KMKernel::activeReaderWindow
which doesn't work in kontact anyhow.
CCMAIL: 67644-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=268877
signals from being emitted.
This should fix the sent folder count updating bug. If it does not for
you, please reopen.
Patch Ok'ed by Till (Don also agreed that quiet() can be removed).
CCMAIL: 63670-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=260199
#define kernel KMKernel::self()
to
#define kmkernel KMKernel::self()
because 'kernel' was a much to general term. We really shouldn't repeat the mistakes of the X developers.
I noticed this problem when I played around with KImageEffects. kimageeffects.h contains 'kernel' as parameter of some methods and so the compilation had to fail. We won't need KImageEffects in the near future, but at least we are now prepared and a clash with another 'kernel' can't happen anymore.
svn path=/trunk/kdepim/; revision=252621
the job wasn't properly terminated, so the syncing 'state machine' was kind of stuck.
The underlying design issue is that KIO's connected slaves emit (via Scheduler) a
signal slaveError, totally unrelated to any job, and that killing the slave
kills the jobs _silently_ (without emitting result()).
As discussed with Waldo, the only way to handle this properly is to wait for the
slave to be connected (slaveConnected signal from Scheduler), before assigning
the slave to a job. I didn't rewrite all of kmail for it :) but I changed the
return value of makeConnection to be an enum: Error, Connected or Connecting.
This keeps compat with existing code which just checks it as a bool, but allows
KMFolderCachedImap to wait for the slaveConnected signal before proceeding.
Visually, this does the connection attempt at 0% progress instead of at 30%,
so it looks more logical :)
svn path=/trunk/kdepim/; revision=233801