GNOME Bugzilla – Bug 500203
eog crash when .gnome2/eog is not a directory
Last modified: 2008-10-23 22:36:36 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/eog/+bug/147059 "Binary package hint: eog when opening EOG from any filemanager nothing happens. in a shell i get this error: EOG-ERROR **: file eog-util.c: line 300 (eog_util_dot_dir): assertion failed: (exists) aborting... Aborted (core dumped) ... http://launchpadlibrarian.net/9688509/gdb-eog2.txt EOG-ERROR **: file eog-util.c: line 300 (eog_util_dot_dir): assertion failed: (exists) aborting... Program received signal SIGABRT, Aborted.
+ Trace 179958
Thread NaN (LWP 15873)
cheers. ...
*** Bug 497206 has been marked as a duplicate of this bug. ***
Oh yes, I forgot to answer in bug 497206. The problem is that we currently don't handle the case when ~/.gnome2/eog is a file. So, the possible solutions would be to simply delete the file or trying to move it away safely (renaming it to eog.bak; possibly deleting it if that fails). Which one is the preferable? We should avoid asking the user as he most probably won't know what's going on.
Well. I think there is the very corner case (probably from really old eog versions) when eog for some reason, created that file. And then, it would be sane to remove the file. And there is the other really unlikely corner case, when that file was created for some strange reason by a user (or other application?). Not sure how to handle this in a consistente and safe way. But changing the assertion to a warning comes to my mind, eitherway.
Just another possibility I just saw in my .gnome2 folder. We could call EOG's dot-dir "eog.d" instead of just "eog" (yelp and bug-buddy are examples doing it).
That could do it. But we would need to rename the .eog directory, if exists and is a directory, so that users do not loose their customized toolbars.
Leaves one question though: What to do if "eog.d" exists and is no directory?
*** Bug 505236 has been marked as a duplicate of this bug. ***
*** Bug 506731 has been marked as a duplicate of this bug. ***
Created attachment 105869 [details] [review] make room for dotdir Maybe we can solve this for 2.22: This patch tries to move files that come into its way away using g_mkstemp.
Created attachment 105881 [details] [review] just print a warning instead Second approach. After finding out that a really "safe" file renaming (without accidentially overwriting another programs data during context switch) is a pretty hard task (and considering that there are comparatively few people suffer from this), we decided to take an easier approach. Now, we display a warning on the console instead of asserting. Changed settings like a custom toolbar layout won't be saved until the user moved that file away (or deleted it).
Considering the security implications and that it is a very corner case (really few reports for a feature that's been out for 6 months now), I think that the warning is enough. If more reports come out, we should consider finding a safe way of moving the file away. Patch looks ok, Felix.
Okay, committed it. 2008-02-25 Felix Riemann <> * src/eog-application.c: (eog_application_init), (eog_application_save_toolbars_model): * src/eog-util.c: (eog_util_dot_dir): Don't assert if we cannot create the user preferences directory because a file with the same name blocking it. Log a warning instead. Attempts to save the toolbar layout will be ignored until the user moved the file away. Fixes bug #500203. ---- This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
*** Bug 520712 has been marked as a duplicate of this bug. ***
*** Bug 556288 has been marked as a duplicate of this bug. ***