If photos.db is not writeable, f-spot crashes with "Mono.Data.SqliteClient.SqliteExecutionException"

[Mary Gardiner]

Binary package hint: f-spot

Actual behaviour:

If photos.db is not writeable by the current user, f-spot dies with errors much like the following:

Mono.Data.SqliteClient.SqliteExecutionException: SQL logic error or missing database
  at Mono.Data.SqliteClient.SqliteCommand.ExecuteStatement (IntPtr pStmt, System.Int32& cols, System.IntPtr& pazValue, System.IntPtr& pazColName) [0x00000]
  at Mono.Data.SqliteClient.SqliteCommand.ExecuteStatement (IntPtr pStmt) [0x00000]
  at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior, Boolean want_results, System.Int32& rows_affected) [0x00000]
  at Mono.Data.SqliteClient.SqliteCommand.ExecuteNonQuery () [0x00000]
  at Banshee.Database.QueuedSqliteCommand.Execute () [0x00000]
   at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal)
   at GLib.Idle+IdleProxy.Handler()
   at Gtk.Dialog.gtk_dialog_run(IntPtr )
   at Gtk.Dialog.Run()
   at ImportCommand.ImportFromFile(.PhotoStore store, System.String path)
   at MainWindow.HandleImportCommand(System.Object sender, System.EventArgs e)
   at System.Reflection.MonoMethod.InternalInvoke(System.Object , System.Object[] , System.Exception ByRef )
   at System.Reflection.MonoMethod.Invoke(System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(System.Object obj, System.Object[] parameters)
   at System.Delegate.DynamicInvokeImpl(System.Object[] args)
   at System.MulticastDelegate.DynamicInvokeImpl(System.Object[] args)
   at System.Delegate.DynamicInvoke(System.Object[] args)
   at GLib.Signal.ClosureInvokedCB(System.Object o, GLib.ClosureInvokedArgs args)
   at GLib.SignalClosure.Invoke(GLib.ClosureInvokedArgs args)
   at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data)
   at Gtk.Application.gtk_main()
   at Gtk.Application.Run()
   at FSpot.Driver.Main(System.String[] args)
cleanup context

This error does not occur immediately after launch, but does occur when selecting a directory for import (and undoubtedly at other times).

Expected behaviour:

A much more user-friendly error, ideally presented within the f-spot GUI rather than on the command line.

ProblemType: Bug
Architecture: i386
Date: Sat Dec 12 18:24:35 2009
DistroRelease: Ubuntu 9.10
Package: f-spot 0.6.1.5-0ubuntu1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_AU.UTF-8
 SHELL=/usr/bin/zsh
ProcVersionSignature: Ubuntu 2.6.31-16.52-generic
SourcePackage: f-spot
Uname: Linux 2.6.31-16-generic i686

[Pedro Villavicencio (pedro)]

Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

[Mary Gardiner (puzzlement)]

I don't see in what respect it's a duplicate: in my scenario, there's plenty of free space, the permissions on photos.db are wrong in such a way as that it's not writeable. The result sounds completely different too: the desktop does not lock up as described in bug 34074, f-spot crashes (silently, unless being run from a console, in which case there's a specific error not mentioned in bug 34074.

[Sebastien Bacher (seb128)]

the software could handle broken configs in a better way but it would rather be interesting to not have things breaking first, do you know what you did to have those permissions wrongly set there? was that an user mistake or something which happened while user a software shipped with ubuntu?

[Sebastien Bacher (seb128)]

Changing the importance to low, having broken permissions seems really a corner case if that's not the software leading to those

[Mary Gardiner (puzzlement)]

Having the permissions wrong was user error: both ~/Photos and photos.db are on a Samba share which I hadn't mounted in such a way as to get the correct user id.

[Pedro Villavicencio (pedro)]

backtrace on the upstream bugtracker is the same than this one. that's why i marked it as a duplicate, but you're more than welcome to send it there.

[Andrew Bennetts (spiv)]

> backtrace on the upstream bugtracker is the same than this one.

Pedro, there is no backtrace on the upstream bug report of bug 34074
(https://bugzilla.gnome.org/show_bug.cgi?id=322541) that I can see, and
none of the duplicates of the upstream bug report have similar
backtraces. I haven't been able to find any duplicates by searching
bugzilla.gnome.org either. Can you please point to where there is a
backtrace “the same as this one” before marking this as incomplete or a
duplicate?

  status confirmed
  subscribe