GNOME Bugzilla – Bug 247217
Cannot delete other user's folder stuck at searching...
Last modified: 2013-07-23 14:27:56 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: If you have opened an other user's folder and for some reason ( changed permissions for example ) you can no longer connect to it, in the folder tree it shows as Searching... If you right click on the other user's folder ( displayed as Searching... ) and select delete you get a pop up that says 'Really delete folder "Searching.."?'. Needless to say that doesn't work, Error "The specified folder was not found". You have to delete the parent folder ( Mike's Folders ), which is a pain if you have other folders for that user open. Expected Results: Deletes folder Additional Information: Machine Configuration ------------------------------------------------------------------ Linux tlee 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux evolution-1.4.3.99.0.200307281501-0.snap.ximian.5.1 ximian-connector-1.4.4-0.ximian.5.1 libsoup-1.99.24.0.200307281501-0.snap.ximian.5.1 libgal19-0.19.2-4 libgal2.0_3-1.99.8.99.0.200307281501-0.snap.ximian.5.1 gtkhtml-1.0.4-3 gtkhtml3.0-3.0.7.0.200307281501-0.snap.ximian.5.1 evolution-pilot-1.4.3.99.0.200307281501-0.snap.ximian.5.1 pilot-link-0.11.3-3 gnome-pilot-2.0.10.0.200307281501-0.snap.ximian.5.1 gnome-pilot-applet-2.0.10.0.200307281501-0.snap.ximian.5.1 gnome-pilot-conduits-2.0.9-0.ximian.5.1 gnome-mime-data-2.0.0-9 gtk+-1.2.10-22 gtk2-2.0.6-8.ximian.80.1 bonobo-1.0.21-1.ximian.1 libbonoboui-2.0.1-2 libgnomecanvas-2.2.0.2-0.ximian.5.2
Created attachment 42754 [details] E2K_DEBUG output from session trying to remove rocky's calendar
Unfortunately, this can't be fixed currently because of the same soup bug affecting http://bugzilla.ximian.com/show_bug.cgi?id=43332 and bug 246724; the folders will almost always show up as being unreadable if you look at them at startup time, so if we add code to remove them in that case, the whole hierarchy will end up being deleted every time you start evo. :-/
fixed with latest soup
sorry, not true. it's now *fixable*, but not yet fixed on -1-4-branch
so, clarifying what needs to be done here: when the ExchangeHierarchyForeign first scans the tree at startup time, it should remove any folders that it gets "permission denied" on.
We need to test the behavior now.
The "evolution-exchange" package only supports Exchange 2000 and 2003 servers. Newer versions such as Exchange 2007 and 2010 are not supported by "evolution-exchange". It is required to use the package "evolution-ews" (or to some extend "evolution-mapi") for newer version fo Exchange servers. If the problem/request described in this report still happens with a recent version of "evolution-ews" or "evolution-mapi", please add a comment to this report (and update the "product" setting accordingly if possible). There are currently no plans to continue the development of the package "evolution-exchange", so this report will soon be closed as WONTFIX. Thanks for your understanding and sorry that the reported problem was not solved in time in the package "evolution-exchange".
evolution-exchange only supports the older Microsoft Exchange server versions 2000 and 2003. The last stable release of evolution-exchange was 3.4.4 which took place a year ago. evolution-exchange is now deprecated and not under active development anymore. It is unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again. Also feel free to reopen this ticket and change the "Product" field accordingly if the reported issue still happens with a recent version (newer than version 3.6) of one of those Exchange backends that are still supported. Please see https://help.gnome.org/users/evolution/3.8/exchange-connectors-overview.html for more information on available backends.