GNOME Bugzilla – Bug 322541
Crashes When Disk Full
Last modified: 2018-07-01 08:49:53 UTC
If the disk that ~/.gnome2/f-spot/photos.db is located on is full, F-Spot will crash if you try to do anything that writes to the database (eg tagging a photo, etc). It would of course be preferable to catch these exceptions and display an error, not crash. :) It's easy to think that people run out of hard drive space very unfrequently, but I know many users whose computers are always nearly out of hdd space.
I'm not sure where the best place to catch this is.
A bit more information in duplicate bug #333341
*** Bug 333341 has been marked as a duplicate of this bug. ***
*** Bug 335090 has been marked as a duplicate of this bug. ***
See also bug #322805 regarding removable media. F-Spot needs to handle errors when writing anything.
There are 2 problems, described in this bug: 1. F-Spot crashes, when there are no free space in volume, where ~/.gnome2/f-spot/photos.db is located 2. User don't gets ant warning message, when volume, where user's home is located is on low disk space. First problem must be fixed in f-spot, while for second problem there should be a daemon in GNOME, which check's for free space in volume. AFAIK gnome-volume-manager can monitor free space in the volume, so, maybe we should report a bug against it ?
It happened to me. F-Spot crashed. And, whats worse, The photos.db was empty after crashing. :-| Starting f-spot than throws an Exception in Banshee.DatabaseWhatever saying "unsupported version of sqlite".
I'd rather call this an SQLite bug, even if there is no disk space to write new changes, it should at least be atomic to prevent against corruptions of existing data.
(In reply to comment #7) > It happened to me. F-Spot crashed. > And, whats worse, The photos.db was empty after crashing. :-| > That may be a completely new photos.db; isn't there a another db file in the folder that contains your old db?
(In reply to comment #9) No, there was no other db file there. And I don't think that it was a new photos.db as there where no tables in, it had a size of 0 kB and f-spot could not recognize it as database file.
From a quick glance on the sqlite.org site, there is code that returns SQLITE_FULL in a write operation if the disk is full. (http://www.sqlite.org/cvstrac/chngview?cn=1994) . I haven't looked at the code in f-spot, but I imagine that catching the SQLITE_FULL Exception (I assume it gets thrown by the bindings, otherwise it's a bindings bug obviously) whenever we do a ExecuteNonQuery call should be doable?
Or we could do a very bad thing, and check that there is atleast a couple of MB free where photos.db resizes. Otherwise we refuse to start... Should be simple... That said, we should catch the exceptions if we do not, but by then I presume it is to late, since the report stated that photos.db was EMPTY.
Exactly the same happend to me with a current SVN version. The disk ran full during an import which results in a 0 bytes photos.db and the before mentioned error message. There is not only the data loss but f-spot isn't starting anymore and this message is only been printed to the console. Users without deeper knowledge of f-spot can't fix this themselves :( Maybe the import could be handled in a pseudo transaction: - Create a copy of photos.db - Import images - If there is an exception remove the copied images and restore the original photos.db Error messages during startup should be brought to the GUI.
*** Bug 556950 has been marked as a duplicate of this bug. ***
My case (as it was described in Bug 556950) was a bit different: photos.db was not corrupted. I guess F-Spot ran out of space when writting jpeg files rather than the database. The crash was less painful, but still not nice.
(In reply to comment #15) > My case (as it was described in Bug 556950) was a bit different: photos.db was > not corrupted. I guess F-Spot ran out of space when writting jpeg files rather > than the database. The crash was less painful, but still not nice. iirc f-spot doesn't crash when it cannot write photos. can you reproduce it? if so run f-spot --debug and make it crash, and post the latest error lines. if the error is related to sqlite or database you're here, otherwise i was wrong.
That was only my guess. The only facts are: 1. F-Spot crashed during import 2. disk was full after the crash 3. The database was ok, but not all images have been imported. For those imported, the thumbnails still had the black frame. I would prefer not to experiment with my F-Spot installation, though.
*** Bug 572309 has been marked as a duplicate of this bug. ***
*** Bug 587555 has been marked as a duplicate of this bug. ***
*** Bug 555424 has been marked as a duplicate of this bug. ***
Maybe we could calculate the disk space needed by the import first and refuse to do it if there is not enough space at the destination.
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.