Ubuntu

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

Reported by Fabián Rodríguez on 2006-03-08
20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
F-Spot
New
Critical
f-spot (Ubuntu)
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
Andrew Mitchell (ajmitch) wrote :

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

Changed in f-spot:
status: Unconfirmed → Rejected

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

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
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.

Andrew Mitchell (ajmitch) wrote :

Lowering priority as it's a feature request.

Changed in f-spot:
importance: Medium → Low
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
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

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 .

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.

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
Fabián Rodríguez (magicfab) wrote :

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

Changed in f-spot (Ubuntu):
importance: Low → Medium
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
To post a comment you must log in.
This report contains Public information  Edit
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.