GNOME Bugzilla – Bug 247977
Empty Trash on Exit does not work
Last modified: 2003-09-25 02:57:32 UTC
Description of Problem: Steps to reproduce the problem: 1 - Check the option "Empty Trash Folder on exit" 2. Delete some mails and check your Trash 3. Exit Evolution 4. Open Evolution and check your Trash folder Actual Results: Mails are still in the Trash folder Expected Results: No more mails in the Trash How often does this happen? Always Additional Information: Evoltion 1.4.4 via ximian, Redhat 9, 2.4.20-20.9. For me this is a long time bug ...from 1.2 if I can remember.
Seems to work for me.
works fine for me too... in fact, if it were not for this feature, none of my mail would be getting expunged (since the current development branch I am working on does not implement the Expunge menu yet - will probably work on that next)
I know this bug is not on every server. My friend, evo 1.2.2 / RH9 up2dated, same machine as mine, no bug. A second one, fresh install from RH9, ximian update via red-carpet to 1.4.4 : same bug. Launching evolution in a terminal, and closing it gave me this message : $ evolution (evolution:8303): GLib-GObject-WARNING **: gsignal.c:2010: instance `0x837de80' has no handler with id `2595' $ Maybe it helps. Maybe not. Just ready to help.
Close Evolution. From a terminal run export CAMEL_VERBOSE_DEBUG=1;evolution Please paste terminal output to this report (particulay the last lines that appear when you quit Evolution and it expunges messages on exit)
Sorry, but it does nothing more. $ export CAMEL_VERBOSE_DEBUG=1;evolution (evolution:9021): GLib-GObject-WARNING **: gsignal.c:2010: instance `0x8369930' has no handler with id `2596' $ When I expunge some folders, everything seems to be normal, see below : $ export CAMEL_VERBOSE_DEBUG=1;evolution Searching for changed matches '(match-all (system-flag "Deleted"))' Vfolder 'Trash' subfolder changed 'home/pdidier/evolution/local/OVH' changed 1 added 0 removed 0 Vfolder auto-update uids match: 32 adding uid '32' [newly matched] Vfolder 'Trash' subfolder changed 'home/pdidier/evolution/local/OVH' changed 0 added 0 removed 1 removing uid '32' Vfolder 'Trash' subfolder changed 'home/pdidier/evolution/local/Inbox-PERSO' changed 0 added 0 removed 1 removing uid '9967' (evolution:9009): GLib-GObject-WARNING **: gsignal.c:2010: instance `0x84bc5c0' has no handler with id `10075' I was just wondering if gsignal.c had nothing to do with trapping signal , and so launching some action before closure... My 2 cents .
More testing ... this is what I see, not what I understand ;-) I hope it will help you, because it does not speak a lot to me ! - Open evolution - Delete 4 mails ( mails from my SPAM folder) - Check the Trash (4 mails inside) - Exit Evolution - Open Evo again - We canno't see the mails in the Trash ... - Delete one more mail - Check the Trash, I have 5 mails NOW (former 4 one and the new one) { Debug info : Vfolder 'Trash' subfolder changed 'home/pdidier/evolution/local/SPAM' changed 1 added 0 removed 0 Vfolder auto-update } ( The auto-update I think make them reappear ?) Then ... if I colse Evo, I clean the new mail only, or none sometimes. If I want to really ge rid of ALL DELETED MAILS ...this is the way to do : - Open Trash Vfolder - Undelete one mail !!! - Exit Evo { Debug info : removing uid '14' removing uid '18' removing uid '22' removing uid '26' } Here it is ... maybe it helps, maybe it drives you crazy. Me ? I feel OK about this ... love to test ! Good luck.
umm, this is a duplicate of a really old, really well known-to-exist bug.
Works for me in 1.4.4 and 1.4.5
Same problem in 1.4.5 ... just upgrade today via red-carpet.
Joy... a server-side bug?
no, I don't think so. I think it is just a race condition or something. I forget exactly what the problem is. anyways, I'm certain this is a duplicate report. tho the original may have been marked FIXED?
I read many ... almost all bugs on this case... the most explicit one is #13775 and is not fixed ... ( http://bugzilla.gnome.org/show_bug.cgi?id=213775 ). Philippe
ah, yes - that's the one. thanks for finding this :-) *** This bug has been marked as a duplicate of 213775 ***