Description of problem: After upgrading to Fedora 19, I started Evolution and selected the Evolution restore file I had created on Fedora 18. After clicking "Open" on the file dialog, the dialog froze and would no longer accept keyboard input and there was no indication of activity for several minutes. After about 3 minutes, the file dialog finally closed, the next restore dialog appeared, and the keyboard began working again. It is unexpected and bad design for a program to completely seize up when performing normal operations. If an operation is likely to take more than one second, it's consider good practice to put up some kind of status indicator (e.g. a progress bar, a throbber, at least a "working..." status message) so that the user knows nothing has gone wrong. Version-Release number of selected component (if applicable): evolution-3.8.3-2.fc19.x86_64 How reproducible: only tried it once - not sure how to reproduce without wiping the system and starting over Steps to Reproduce: 1. Create a large backup file with Evolution 2. wipe OS, re-install 3. Start evolution, try to restore from backup file Actual results: Program freezes for several minutes (presumably while trying to load the restore file but it may just be a bug) Expected results: Program should continue to operate normally even on a large restore file - it should give a progress bar or other indication that it's still functioning. Additional info: The restore file wasn't particularly large, maybe around 1.5 GB. The Evolution backup file on my other box is often around 10 GB. (haven't upgraded that box to F19 yet, will probably wait to see if this bug is fixed).
Update: ok, this is a much more serious bug that I originally though. I posted the above while waiting for the restore to complete and assumed it would go fine, since it's always worked in the past. However, here's what happened: After about 10 minutes of watching the "restoring..." dialog, I got a "welcome to evolution" dialog with a "continue" button. When I clicked "continue", it took me back to the "You can restore Evolution from a backup file" dialog where we started. There seems to be no way to escape this loop and get Evolution to actually restore the data. If I continue the dialog, it just asks over and over to restore the file (with the 3 minute or so "stuck" time described in the original post above, followed by 10 minutes or so of apparently loading the restore file), then it's back to the beginning again. I finally tried killing the whole process and restarting Evolution, at which point there is no sign of the restored email or account info, it just starts from scratch asking me to provide a restore file or enter my account info manually. It appears Evolution is totally b0rked on F19 as far as restoring from Evolution backups. Any suggestions on a work around or method of restoring my data manually?
More info: after Googling, it appears the Evolution backup/restore process has degraded over the last few versions and restoring fails frequently for many users. In one forum I found a process I followed to "reset" Evolution, so that I could start from scratch: 1. evolution --force-shutdown 2. yum remove evolution 3. rm -rf ~/.local/share/evolution 4. rm -rf ~/.gconf/apps/evolution 5. rm -rf ~/.cache/evolution 6. dconf reset -f /org/gnome/evolution/ (must end with backslash!) 7. gconftool-2 --shutdown (if that doesn't work, do a ps and kill it) 8. gconftool-2 --recursive-unset /apps/evolution (no ending backslash!) 9. yum install evolution Hopefully that will help others stuck with restore bugs. After doing this once, I tried again to do the restore with the same results. As before, it silently fails, no error message, no log file that I can find, and dumps you back at the first dialog screen asking you to input the restore file. From what I'm reading some people are having success by manually extracting the files from their Evolution backup, so I'll be working on that next. I'll post an update if I'm able to find a work-around that allows me access my mail again.
Just speculating here but does Evolution use /tmp to decompress the restore file? I noticed on F19 the /tmp directory has been replaced by something called tmpfs which seems to have severe size limitations that would preclude all but the tiniest restore files from working. I noticed I can't manually decompress the Evolution restore file using mc because it relies on gzip, which apparently uses /tmp and it dies a few minutes into the process saying I'm out of disk space, even though I have around 100GB free on the disk (I think this is related to the new size restrictions on /tmp too)...
Thanks for a bug report. The evolution itself doesn't depend on gzip directly, though it unpacks the file into the right folders through tar command, which might depends on gzip, in which case it depends on the /tmp afterwards, as you pointed above. I guess you can make the /tmp a regular folder when editing the /etc/mtab, replacing the line tmpfs /tmp tmpfs rw,seclabel 0 0 with something on your real drive (or basically moving it away), but I never tried that, thus I cannot guarantee anything on the change, neither if your system will not break even more after restart. In any case, I believe your restore from a backup from Fedora 18 (evolution 3.6.x) will work as expected (you get to your mails) when the limited /tmp issue will be sorted out, which is nothing what can evolution do about, because it only calls command line tools in the background. From that I believe the only left point is that the UI window is stuck during restore, when checking archive content. The problem is that the tar doesn't give much feedback, thus there is nothing to listen too, but I'm upstreaming this anyway, because you are right some kind of feedback will be helpful here, same as no UI freeze during either backup or restore. I moved this part upstream as [1]. Please see it for any further updates. By the way, you do not need to uninstall and install evolution, it's better to stop all background evolution processes (ps ax | grep evolution). You can invoke restore from a backup in File menu, the option is beside the one where you created your backup. [1] https://bugzilla.gnome.org/show_bug.cgi?id=703782
Is there any way we can confirm whether or not Evolution relies on the /tmp directory for restores? If we can identify the cause of this problem with certainty, I can file another, more specific bug for the restore issue. I understand that resorting to the command line and manually reconfiguring the file system to have a more sane /tmp directory set up is probably the best solution for now but it's neither elegant nor user-friendly and will likely be beyond the abilities of the casual user. As an alternative, is there a way to import the Evolution backup file into another program like Thunderbird that might be easier for the casual user until a long-term solution can be found?
(In reply to Steve Rainwater from comment #5) > Is there any way we can confirm whether or not Evolution relies on the /tmp > directory for restores? If we can identify the cause of this problem with > certainty, I can file another, more specific bug for the restore issue. Please note that the dependency on /tmp is indirect, it's not Evolution's fault by any means. If your identification of the issue is correct, then I'd say it's gzip's fault (and the decision maker's fault to limit /tmp to 2GB (it's the value on my machine)). I opened the sources and found that the restore of a new format uses: $ tar xzf https://git.gnome.org/browse/evolution/tree/modules/backup-restore/evolution-backup-tool.c?h=gnome-3-8#n570 while restore of the old backup uses: $ gzip -cd %s | tar xf - ... https://git.gnome.org/browse/evolution/tree/modules/backup-restore/evolution-backup-tool.c?h=gnome-3-8#n599 backup itself uses gzip too: $ tar -chf ... | gzip > filename https://git.gnome.org/browse/evolution/tree/modules/backup-restore/evolution-backup-tool.c?h=gnome-3-8#n353 > I understand that resorting to the command line and manually reconfiguring > the file system to have a more sane /tmp directory set up is probably the > best solution for now but it's neither elegant nor user-friendly and will > likely be beyond the abilities of the casual user. Right, it was meant as a workaround. > As an alternative, is there a way to import the Evolution backup file into > another program like Thunderbird that might be easier for the casual user > until a long-term solution can be found? I do not think so, Thunderbird has no idea of evolution's backup (same as evolution has no idea of Thunderbird backups). It's still tar.gz file, and the main issue is to unpack it. If you are right with gzip, then we are doomed, using Thunderbird or not.
*** Bug 991524 has been marked as a duplicate of this bug. ***
*** Bug 951865 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.