GNOME Bugzilla – Bug 603028
crashes when a filename uses ":"
Last modified: 2009-11-28 17:08:47 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/475811 "F-spot doesn't work since I have upgraded Ubuntu to version 9.10. I get the following error message, when I start It: URI scheme must start with a letter and must consist of one of alphabet, digits, '+', '-' or '.' character. (in `System') I have been using f-spot since it's the main photo gallery in ubuntu, and I have lot of pictures. ... [Debug 21:20:08.580] Query Started : SELECT * FROM photos ORDER BY time DESC, filename DESC [Debug 21:20:08.640] QueryToTemp took 0,059585s : SELECT * FROM photos ORDER BY time DESC, filename DESC [Debug 21:20:08.640] Reloading the query took 0,062687s [Debug 21:20:08.941] PhotosPerMonth took 0,048361s [Debug 21:20:08.943] TimeAdaptor REAL Reload took 0,25309s [Warn 21:20:09.025] Caught an exception - URI scheme must start with a letter and must consist of one of alphabet, digits, '+', '-' or '.' character. (in `System') at System.Uri.Parse (UriKind kind, System.String uriString) [0x00000] at System.Uri.ParseUri (UriKind kind) [0x00000] at System.Uri..ctor (System.Uri baseUri, System.String relativeUri, Boolean dontEscape) [0x00000] at System.Uri..ctor (System.Uri baseUri, System.String relativeUri) [0x00000] at PhotoStore.GetAllVersions () [0x00000] at PhotoStore.Query (Banshee.Database.DbCommand query) [0x00000] at PhotoStore.Query (System.String query) [0x00000] at PhotoStore.QueryFromTemp (System.String temp_table, Int32 offset, Int32 limit) [0x00000] at FSpot.PhotoQuery+PhotoCache.Get (Int32 index) [0x00000] at FSpot.PhotoQuery.get_Item (Int32 index) [0x00000] at FSpot.BrowsablePointer.get_Current () [0x00000] at FSpot.BrowsablePointer.SetIndex (Int32 value, IBrowsableItemChanges changes) [0x00000] at FSpot.BrowsablePointer.SetIndex (Int32 value) [0x00000] at FSpot.BrowsablePointer.set_Index (Int32 value) [0x00000] at FSpot.BrowsablePointer..ctor (IBrowsableCollection collection, Int32 index) [0x00000] at FSpot.PhotoView..ctor (IBrowsableCollection query) [0x00000] at MainWindow..ctor (.Db db) [0x00000] at FSpot.Core.get_MainWindow () [0x00000] at FSpot.Core.Organize () [0x00000] at FSpot.Driver.Main (System.String[] args) [0x00000] ... I put System.Console.WriteLine to PhotoStore.GetAllVersions method to check parameters of Uri constructor, and I get this: . . base_uri = file:///home/zita/Képek/2009/07/31/ filename = DSCF8355%20(M%C3%B3dos%C3%ADtva%20ekkor:%20gThumb%20k%C3%A9pmegjelen%C3%ADt%C5%91).JPG [Warn 21:55:14.014] Caught an exception - URI scheme must start with a letter and must consist of one of alphabet, digits, '+', '-' or '.' character. (in `System') . ... It does seem to be the colon in the filename which causes the crash. I ran a photos.db through an instrumentd f-spot with the following result: ... ... AppendValues ( Gtk.TreeIter, 2003%20Kitchen%20Before) AppendValues ( Gtk.TreeIter, Michigan) AppendValues ( Gtk.TreeIter, Volume%202) AppendValues ( Gtk.TreeIter, Volume%203) AppendValues ( Gtk.TreeIter, 2005-02-12--14:13:46) [Warn 00:53:34.914] Caught an exception - URI scheme must start with a letter and must consist of one of alphabet, digits, '+', '-' or '.' character. (in `System') Notice that as soon as a name with a colon in it shows up f-spot børks. A look at mcs/class/System/System/Uri.cs (part of Mono) shows what happens: as soon as there is a colon in a string and that colon is not at position 0 (which is always an error) or position 1 (which is interpreted as following an MS-DOS/Windows drive letter) the part of the string before the colon is interpreted as an URI scheme (eg http, file, ftp, etc.). This will naturally lead to an error as (in the above example) ' 2005-02-12--14' is not a valid scheme. The solution is for f-spot to %-encode colons in the string before it gets handled by any of Mono's URI-handling functions. It does this for spaces (->%20) but not for colons (->%3A). This should be changed... ..."
This bug is a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=559093
*** This bug has been marked as a duplicate of bug 559093 ***