Version: (using KDE KDE 3.5.5) Installed from: Compiled From Sources Compiler: gcc 4.1.2 OS: Linux I have several folders with thousands of new messages appearing in these on daily basis. I'm marking and deleting most of them. Unfortunately deleting for example ~8000 messages takes several minutes. It's sooo slow. stracing kmail shows that it's reading and writting contents of *each* message (local Maildir) instead of just doing rename() Why it doesn't just rename emails? access("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30465_2.tarm", F_OK) = 0 lstat64("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30465_2.tarm", {st_mode=S_IFREG|0644, st_size=3171, ...}) = 0 access("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30465_2.tarm", W_OK) = 0 open("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30465_2.tarm", O_RDWR|O_LARGEFILE) = 18 fstat64(18, {st_mode=S_IFREG|0644, st_size=3171, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb569f000 read(18, "Return-path: <>\nEnvelope-to: are"..., 4096) = 3171 close(18) = 0 munmap(0xb569f000, 4096) = 0 time(NULL) = 1160950975 access("/home/users/arekm/Mail/trash/tmp/1159465344.30465_2.tarm", F_OK) = -1 ENOENT (No such file or directory) open("/home/users/arekm/Mail/trash/tmp/1159465344.30465_2.tarm", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 18 fstat64(18, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(18, "Return-path: <>\nEnvelope-to: are"..., 3172) = 3172 close(18) = 0 access("/home/users/arekm/Mail/trash/cur/1159465344.30465_2.tarm", F_OK) = -1 ENOENT (No such file or directory) rename("/home/users/arekm/Mail/trash/tmp/1159465344.30465_2.tarm", "/home/users/arekm/Mail/trash/cur/1159465344.30465_2.tarm") = 0 gettimeofday({1160950975, 388382}, NULL) = 0 gettimeofday({1160950975, 389013}, NULL) = 0 gettimeofday({1160950975, 389133}, NULL) = 0 gettimeofday({1160950975, 512273}, NULL) = 0 unlink("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30465_2.tarm") = 0 fstat64(17, {st_mode=S_IFREG|0600, st_size=3758563, ...}) = 0 _llseek(17, 3756032, [3756032], SEEK_SET) = 0 read(17, "\0\0\0\17\0\0\0,\0\0q\0y\0p\0002\0l\0g\0M\0c\0e\0P\000"..., 2531) = 2531 write(17, "`\2\0\0", 4) = 4 write(17, "\5\0\0\0,\0\0s\0k\0k\0r\0s\0l\0M\0006\0/\0s\0O\0E\0p"..., 608) = 608 open("/home/users/arekm/Mail/.trash.index.ids", O_RDWR|O_LARGEFILE) = 18 fstat64(18, {st_mode=S_IFREG|0644, st_size=26081, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb569f000 read(18, "# KMail-Index-IDs V1002\n*xV4\22p\31\0"..., 4096) = 4096 _llseek(18, 0, [4096], SEEK_CUR) = 0 _llseek(18, 4096, [4096], SEEK_SET) = 0 _llseek(18, 4096, [4096], SEEK_SET) = 0 _llseek(18, -4067, [29], SEEK_CUR) = 0 write(18, "q\31\0\0", 4) = 4 _llseek(18, 24576, [24576], SEEK_SET) = 0 read(18, "\0^\251r\0_\251r\0`\251r\0a\251r\0b\251r\0c\251r\0d\251"..., 4096) = 1505 write(18, "\332\252r\0", 4) = 4 close(18) = 0 munmap(0xb569f000, 4096) = 0 access("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30467_2.tarm", F_OK) = 0 lstat64("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30467_2.tarm", {st_mode=S_IFREG|0644, st_size=3169, ...}) = 0 access("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30467_2.tarm", W_OK) = 0 open("/home/users/arekm/Mail/.Test.directory/.PodTest.directory/bulk/cur/1159465344.30467_2.tarm", O_RDWR|O_LARGEFILE) = 18 fstat64(18, {st_mode=S_IFREG|0644, st_size=3169, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb569f000 read(18, "Return-path: <>\nEnvelope-to: are"..., 4096) = 3169 close(18) = 0 munmap(0xb569f000, 4096) = 0 time(NULL) = 1160950975 access("/home/users/arekm/Mail/trash/tmp/1159465344.30467_2.tarm", F_OK) = -1 ENOENT (No such file or directory) open("/home/users/arekm/Mail/trash/tmp/1159465344.30467_2.tarm", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 18 fstat64(18, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(18, "Return-path: <>\nEnvelope-to: are"..., 3170) = 3170 close(18) = 0 access("/home/users/arekm/Mail/trash/cur/1159465344.30467_2.tarm", F_OK) = -1 ENOENT (No such file or directory) rename("/home/users/arekm/Mail/trash/tmp/1159465344.30467_2.tarm", "/home/users/arekm/Mail/trash/cur/1159465344.30467_2.tarm") = 0 gettimeofday({1160950975, 528044}, NULL) = 0 gettimeofday({1160950975, 528666}, NULL) = 0 gettimeofday({1160950975, 528787}, NULL) = 0
You're using IMAP? Then it's probably a duplicate to bug 126793.
No, I'm not using imap, please read carefully: ,,(local Maildir)''
*** Bug 134711 has been marked as a duplicate of this bug. ***
*** Bug 120103 has been marked as a duplicate of this bug. ***
*** Bug 132145 has been marked as a duplicate of this bug. ***
kdepim enterprise from 3.5.9 also show the same nasty behaviour. That's weird that enterprise people aren't annoyed by this behaviour ;-) Didn't test kde 4.0.6X kdepim. Anyway according to marked duplications this bug shouldn't be in "unconfirmed" any longer.
Maybe that deletion job could be done in separate, low priority thread?
3.5.10 is doing the same stupid thing. Does anyone know if kde 4.x kmail behaves differently?
kmail 1.10.3 (from kde 4.1.3) appears to do the same thing ... ive tweaked the output to make it a bit more readable, but here's the strace from a delete in a local maildir stat(".../.mail/trash/tmp/1230370293.7494.WvV10:2,S", 0x54ad8f8) = -1 ENOENT lstat(".../.mail/trash/tmp/1230370293.7494.WvV10:2,S", 0x7fff6dea4820) = -1 ENOENT open(".../.mail/trash/tmp/1230370293.7494.WvV10:2,S", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 38 fstat(38, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(38, "Delivered-To: vapierfilter@gmail."..., 4096) = 4096 write(38, "de?subject=help>\nList-Subscribe: "..., 2228) = 2228 close(38) = 0 stat(".../.mail/trash/cur/1230370293.7494.WvV10:2,S", 0x6a3cb78) = -1 ENOENT lstat(".../.mail/trash/cur/1230370293.7494.WvV10:2,S", 0x7fff6dea48e0) = -1 stat(".../.mail/trash/tmp/1230370293.7494.WvV10:2,S", {st_mode=S_IFREG|0644, st_size=6324, ...}) = 0 stat(".../.mail/trash/cur/1230370293.7494.WvV10:2,S", 0x6a229e8) = -1 ENOENT lstat(".../.mail/trash/cur/1230370293.7494.WvV10:2,S", 0x7fff6dea3880) = -1 ENOENT rename(".../.mail/trash/tmp/1230370293.7494.WvV10:2,S", ".../.mail/trash/cur/1230370293.7494.WvV10:2,S") = 0 unlink(".../.mail/misc projects/cur/1230370293.7494.WvV10") = 0
*** This bug has been confirmed by popular vote. ***
*** This bug has been marked as a duplicate of bug 126793 ***
are you sure this is a dupe ? Bug 126793 seems like it's specific to IMAP and how it hangs. we've clearly diagnosed the problem here with maildir ... no one has done that with IMAP. the IMAP things looks more like a network latency issue (and ive seen the same thing with IMAP accounts -- unlike my maildir ones).
kmail 4.4rc1 does the same thing (waiting for ~20 minutes to delete 19k emails... and it still didn't finish)
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.