it will be reused in the target folder, on move, and overwrite the entry
for any existing entry at that row, thereby bringing the index out of sync
with reality.
svn path=/trunk/KDE/kdepim/; revision=812625
-use K_GLOBAL_STATIC for static data
-an attempt to fix possible crashes and "null messages appearing in folders like outbox"
Details:
M kmail/kmfolderindex_sqlite.cpp
M kmail/kmfolderindex.h
* executes "DELETE FROM messages WHERE id=.." for every for messages
with 0 serial number, especially for the outbox
* removed commented-out old impl.
M kmail/kmmessage.h
use K_GLOBAL_STATIC
M kmail/kmfoldermaildir.cpp
* minor change
M kmail/jobscheduler.cpp
M kmail/jobscheduler.h
* ~JobScheduler() use qDeleteAll() (and clear for sanity)
M kmail/networkaccount.cpp
* use K_GLOBAL_STATIC
* use value() to avoid inserting 0 values
* NetworkAccount::resetConnectionList(): use remove() instead of inserting 0
M kmail/kmmessage.cpp
* use K_GLOBAL_STATIC
M kmail/kmcommands.cpp
* KMMoveCommand::execute(): skip mesages with serial number == 0
-this avoids crashes when user tries to clean up a folder with "no subject" items
M kmail/kmmsgbase.cpp
* #ifdef code related to using_mmap when using sqlite mode
M kmail/networkaccount.h
* use QPointer<KIO::Slave> mSlave and bits for boolean members
svn path=/trunk/KDE/kdepim/; revision=809620
used for mbox storage
BTW, I think we should discuss further enabling displaying warnings about recreating outdated indices for maildir:
in sqlite mode, I've seen way too many of them, so perhaps there is a way to fix timestamps instead of displaying the warning
svn path=/trunk/KDE/kdepim/; revision=805511
to skip message "The index of folder .. seems to be out of date" for maildir folders
This can probbaly fix recently reported issues with displaying the message for maildir folders.
-int KMFolderIndex::writeMessages( KMMsgBase* msg, bool flush, FILE* indexStream ):
added overload with indexStream arg, which simplifies KMFolderIndex::writeIndex() code
and avoids dangerous side effects
(note: this apparently was not a source of problems, though)
CCMAIL:kde-pim@kde.org
svn path=/trunk/KDE/kdepim/; revision=805447
from
/branches/work/kmail-nommap (r799390..804487)
/branches/work/kdepim-nommap/kmail (r804484..804960)
The SQLite mode is currently enabled only on Windows (by KMAIL_SQLITE_INDEX define),
so on !Windows, the code for standard 'mmap' mode is compiled.
CCMAIL:kde-pim@kde.org
svn path=/trunk/KDE/kdepim/; revision=805075
- Add kWarning when index is rebuilt because it is out of date
- Add message box asking if the user really wants to manually
recreate the index
svn path=/trunk/KDE/kdepim/; revision=804158
Added a queuing mechanism to prevent several KDirSize jobs from running concurrently when several maildir folders are checked for their size.
CCBUGS: 149414
svn path=/trunk/KDE/kdepim/; revision=770314
folders >2GB won't show up correctly on 32 Bit systems.
I hope I found all places were the conversion was necessary.
I couldn't really test this, as i don't have a 64 Bit system, but I should
work.
BUG: 151155
svn path=/trunk/KDE/kdepim/; revision=751020
Forward port of:
>SVN commit 633411 by adridg
>mIndexStreamPtrLength comes from struct stat, should be a size_t. It *is*
>a size (of the index file) after all. Also make the size information
>available in the KMFolderIndex API and add a touch of documentation.
>We need the size information to be able to judge if a KMMsgBase
>object has index information or not.
Forward port of:
>SVN commit 633413 by adridg
>Stop KMail from crashing all the time in PIM+;
>check if the data range in the index for this message would make sense at all.
>If not, no string part. Needs r. 633411 API changes.
This is another example why having some many branches is not a good idea.
Adriaan, Ismail: Are there more unported bugfixes in the 3.5.5+ branch?
CCMAIL: groot@kde.org
CCMAIL: onurf@su.sabanciuniv.edu
svn path=/trunk/KDE/kdepim/; revision=706981
for the new kDebug/kError/kWarning/kFatal syntax.
You can use the following command to find 'old' code:
egrep -r -A 5 '(kDebug|kError|kWarning|kFatal).*' * | grep -v ".svn" | grep "<< *endl;"
svn path=/trunk/KDE/kdepim/; revision=695781
keeping the msginfo pointer around in the message object, and restoring it on
unGet. Should help with a whole class of crashes around filtering, searching
etc. Original patch by Ingo and Andreas, with some fixes and memleak plugs
in corner cases by me. We'll testdrive this a while in enterprise branch, let's
see how it behaves.
CCMAIL: a.gungl@gmx.de
CCMAIL: ingo@kde.org
svn path=/branches/kdepim/enterprise/kdepim/; revision=694327
color for the folder name, to help improve the usability of working
with quota'd folders.
Resolves kolab merge item 22. Forward port of enterprise commits:
669156, 671804, 677689, 680527
svn path=/trunk/KDE/kdepim/; revision=691345
SVN commit 662110 by wstephens:
3.5+ version of Till's dimap mail loss fix, see r662047
For reference :
SVN commit 662047 by tilladam:
Apply ported version of the mail loss debugging and explicit deletions patch,
which I've been developing with the help of some adventurous users. Thanks!
This tracks all deletions that happen through user actions and adds a check
to the sync making sure that only things that were explicitely deleted
are removed during sync. If unsure, the sync now re-downloads (duplicates)
instead of removing mails, which should be safer. Also adds a lot of
conditional debugging and refactors open/close to duplicate less code.
Will has a ported version of this for 3.x, which will go into pim+ shortly.
SVN commit 678604 by tilladam:
Clear the cache of explicitely deleted uids early enough, right after successful
deletion on the server, so messages taken during getting of messages (because of
filtering) are properly remembered. Fixes kolab/issue1792.
svn path=/branches/KDE/3.5/kdepim/; revision=680182
kmail. Add the ability to use a configurable color for the
folder name and size when it is close to a configurable quota
threshold (provided the folder has quota info in the first
place). Implement size retrieval for mbox and maildir storage.
(prokde35 w1-6)
svn path=/branches/kdepim/enterprise/kdepim/; revision=669156
SVN commit 633071 by winterz:
merge SVN commit 632062 by adridg:
After updating KMail and throwing away index files, I encountered a file which has charset= set, and that triggered
a QGList warning when subscripting an empty string; adding this extra check for empty charsets stops crashing after
that warning.
SVN commit 633069 by winterz:
merge SVN commit 632089 by adridg:
TRUE and FALSE are C-isms, use C++ keywords instead
merge SVN commit 632360 by adridg:
Indentation style is spaces; there's crashes in here occasionally after removing index files, rather peculiar.
svn path=/branches/kdepim/enterprise/kdepim/; revision=667618
which I've been developing with the help of some adventurous users. Thanks!
This tracks all deletions that happen through user actions and adds a check
to the sync making sure that only things that were explicitely deleted
are removed during sync. If unsure, the sync now re-downloads (duplicates)
instead of removing mails, which should be safer. Also adds a lot of
conditional debugging and refactors open/close to duplicate less code.
Will has a ported version of this for 3.x, which will go into pim+ shortly.
svn path=/branches/kdepim/enterprise/kdepim/; revision=662047
This obviously reintroduces issue661, "forwarding emails can produce bad signature", which will have to be fixed another way once I get more infos about it.
Also remove getMsgString from all folder classes, since it's now unused; getDwString is used instead.
svn path=/branches/kdepim/enterprise/kdepim/; revision=650094
forward port SVN commit 614058 by kainhofe
Make RFC 2231-encoded attachment names work. Patch approved by Ingo (the issues he had were corrected).
RFC 2231 defines an enhanced encoding for attachment filenames, and thunderbird
apparently implemented this encoding. RFC 2231 allows one field to be split
across multiple numbered entries of the form fieldname*0=....;
fieldname*1=...; fieldname*2=...; or fieldname*0=....; fieldname*1=...; fieldname*2=...;
All these entries first need to be concatenated to form the full value of the field.
Here's a real-life example:
--------------060807060608070200030605
Content-Type: application/vnd.ms-excel;
name*0*=ISO-8859-15''%41%46%42%D6%20%42%65%73%65%74%7A%75%6E%67%73%6C%69;
name*1*=%73%74%65%20%53%74%61%6E%64%20%32%30%30%36%2D%31%32%2D%31%39%2E;
name*2*=%78%6C%73
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename*0*=ISO-8859-15''%41%46%42%D6%20%42%65%73%65%74%7A%75%6E%67%73%6C;
filename*1*=%69%73%74%65%20%53%74%61%6E%64%20%32%30%30%36%2D%31%32%2D%31;
filename*2*=%39%2E%78%6C%73
As a result, KMail shows %39%2E%78%6C%73 as the file name in both the message
preview panel as well as in the mime tree.
With this patch, KMail correctly shows the proper filename.
The patch adds one static method to collect all parts of rfc 2231-encoded
params into one single string. That method is then used in two different
places for the name and the filename props.
One minor problem remains, though: As the mime library does not have support
for rfc2231 encoded attachments, the message is not shown with the attachment
icon in the message list.
svn path=/trunk/KDE/kdepim/; revision=641088