Bug 800567 - Moving and deleting messages is very slow and fails without long pauses
Summary: Moving and deleting messages is very slow and fails without long pauses
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 15
Hardware: i686
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-06 18:08 UTC by Martin Gregorie
Modified: 2012-03-07 09:08 UTC (History)
3 users (show)

Fixed In Version: evolution-3.2.3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-07 09:08:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Martin Gregorie 2012-03-06 18:08:22 UTC
Description of problem:
=======================
When dragging messages from the 'Send' folder to user-created folders
a red notice saying:
"
  Error while Moving messages into folder Personal/Jim xxxxxx.

  Cannot transfer message to destination folder: No such file or directory
"
if the drag is done fast. However, if the mouse button in pressed and held on the message for at least 4 seconds and then held down for at least another 4 seconds on the destination folder this error does not occur. I have not (yet) seen the problem when moving message between user created folders. Thids os not a critical problem, but it is extremely annoying and reflects badly on the product.

I have Evolution configured to empty the 'Trash' folder on exit. This operation is very much slower than it was under Fedora 14 with the corresponding version of Evolution.

Version-Release number of selected component (if applicable):
=============================================================
3.0.3-1.fc15


How reproducible:
=================
Very. Guaranteed to happen any time I drag a message from 'Sent' to a 
user-created folder by a grab'n drag with no pauses.


Steps to Reproduce:
===================
1. Send somebody a message
2. Open the 'Sent' folder
3. Click on the message and, without any pauses, drag it onto a 
   user-created folder and immediately release the mouse button.
  
Actual results:
===============
A red rectangle appears in the top of the 'Send' folder saying that the destination folder can't be found. See above for the exact wording.
After clicking the 'Dismiss' button in the message, subsequent attempts to move the message won't work until you have (1) select a different folder and (2) reselected the 'Sent' folder.

Expected results:
=================
The selected message is transferred to the destination folder.


Additional info:
================
The glacial speed with which 'Trash' is emptied just happens: Evolution is always very slow to exit if there are messages in 'Trash'. While 'Trash' is being emptied the disk activity light remains hard on.

Linux version 2.6.42.7-1.fc15.i686.PAE (mockbuild.fedoraproject.org) (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) ) #1 SMP Tue Feb 21 01:56:51 UTC 2012

I last ran 'yum upgrade' on the evening of Friday, 2nd March 2012.

Comment 1 Martin Gregorie 2012-03-06 18:15:40 UTC
This may or not be relevant, but I keep /home in its own partition where it is never reformatted. I did the upgrade from F14 to F15 as a clean install - all partitions except /home are reformatted as part of this process.

When Evolution 3.0.3 was first run after the upgrade it upgraded the folder structure to bring it into line with its requirements. No errors were reported during this process.

Comment 2 Milan Crha 2012-03-07 09:08:13 UTC
Thanks for a bug report. I tried to reproduce this with current stable version, which is evolution-3.2.3, in Fedora 16 (the upcoming Fedora 17 will have even newer evolution-3.4.0), and I cannot reproduce the issue with drag & drop from a Sent to another On This Computer folder there, it works correctly. I suggest to either upgrade to Fedora 16, or wait few weeks and upgrade directly to Fedora 17.


Note You need to log in before you can comment on or make changes to this bug.