F-Spot does not warn user if the free space is low before importing photos

Bug #34074 reported by Fabián Rodríguez
20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
F-Spot
Won't Fix
Critical
f-spot (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Also see a related Gnome Bugzilla report:
http://bugzilla.gnome.org/show_bug.cgi?id=322541

After importing a large number of pictures, the main hard disk may become full and all applications stop responding without any indication of low disk space. Mouse navigation works, but no applications will start from GUI.

Steps to reproduce:

1) fresh install of Dapper (nightly March 5th, updated) to a 10GB disk with standard partitioning: full disk erase, 2 partitions of which one is swap.
2) fresh install of f-spot
3) Import of large library of pictures. Default option copies the pictures to the hard disk, without apparent disk space check from either f-spot or dapper
4) When hard disk is full, all applications stop responding. Login through GUI doesn't work either.

Workaround:
1) Go to a TTY console using CTRL-ALT-F1, login and "rm -rf ~/Photos" directory to make space on hard disk
2) Erase "~/.gnome2/f-spot/photos.db" to reset f-spot database

Desired functionality:
f-spot should check for disk space availability before starting importing any size of pictures library in order to prevent an aborted and possibly corrupted import process

Dapper should check for low disk space in order to prevent permanent lockup of a system. Average users may not want/know how to go about the workaround described.

description: updated
Revision history for this message
Andrew Mitchell (ajmitch) wrote :

Not an f-spot bug, please refile/reassign against an appropriate package

Changed in f-spot:
status: Unconfirmed → Rejected
Revision history for this message
Mantas Kriaučiūnas (mantas) wrote : Ubuntu becomes unstable when there are no free space in user's home

There are minimum 3 problems, described in this bug:

1. F-Spot doesn't check, if there are enough free space in volume, where ~/.gnome2/f-spot/photos.db is located
2. User don't gets a warning message, when volume, where user's home is located, is on low disk space.
3. Login through GUI (gdm) doesn't work when there are no enough free space in users home partition.

First problem must be fixed in *f-spot*, so, I'm reopening this bug, because f-spot *should check for disk space* availability *before starting importing* any size of pictures library in order to prevent an aborted and possibly corrupted import process.

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 or assign a bug against it ?

For login problems, when there are no free space, several bugs are reported already, for example bug #41170

Revision history for this message
Mantas Kriaučiūnas (mantas) wrote : Re: Dapper becomes unstable when disk full after f-spot import

this is f-spot bug, because f-spot *should check for disk space* availability *before starting importing* any size of pictures library in order to prevent an aborted and possibly corrupted import process.

Changed in f-spot:
status: Rejected → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

Huh? Unix is not a single-tasking operating system, and it's entirely possible that some other process is creating or appending to files while f-spot is running. While perhaps f-spot should check for disk space up-front and give a warning, it's much more important that it should deal gracefully with ENOSPC if and when it happens, and clean up after itself.

Nowadays, at least in Edgy, you get a pop-up warning on the desktop when you're running low on disk space.

Revision history for this message
Andrew Mitchell (ajmitch) wrote :

Lowering priority as it's a feature request.

Changed in f-spot:
importance: Medium → Low
Revision history for this message
Fabián Rodríguez (magicfab) wrote :

This is hardly a feature request. Bug # 41170 is closely related but I think at the application level we need a check to prevent lengthy and potentially unsuccessful importing of media leading to a complete session lockout. I like Colin's suggestion, however we need that warning to *also* happen *before* the actual import, if space is obviously not enough.

Changed in f-spot:
status: Unknown → New
Revision history for this message
neighborlee (online-heartseed) wrote :

Was this ever solved, or did it just get placed somewhere else or written off as not a bug ?

thx for your thoughts.

lee

Revision history for this message
neighborlee (online-heartseed) wrote :

It should have been changed to NON low prior, as noted by last poster, but I see no dialogue about the change .

Revision history for this message
rdb (rdb) wrote :

I fully agree. Don't stamp a real bug like unimportant so easily or it will end at bottom of the list and nobody every looks at it anymore.

Revision history for this message
Rob Frohne (frohro) wrote :

This still has not been fixed as of 0.5.0.1 at least. It bit my wife last night. Fortunately the OS has been made more rubust to this problem and we were able to go delete some files. The messages it gives when fspot fails due to no disk space isn't easily recognized as that, but df -h certainly indicates the problem. The other good news is that if you delete files making room, then the import recovers.

Rob

Changed in f-spot (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Fabián Rodríguez (magicfab) wrote :

FYI, I won't be following up on this bug.

Changed in f-spot (Ubuntu):
importance: Low → Medium
Revision history for this message
Emily Cartier (elacartier) wrote :

This bug still exists in f-spot 0.6.1.5, in Ubuntu 9.10.

Changed in f-spot:
importance: Unknown → Critical
Changed in f-spot:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.