Summary: | Deleting many maildir messages very slow | ||
---|---|---|---|
Product: | [Unmaintained] kmail | Reporter: | Arkadiusz Miskiewicz <arekm> |
Component: | maildir | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | bjoern, divan, jseward, tma.klein, vapier |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Arkadiusz Miskiewicz
2006-10-16 00:24:37 UTC
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. |