GNOME Bugzilla – Bug 483779
Error importing pictures when filename includes %XX (where XX is valid hex)
Last modified: 2009-08-12 11:16:40 UTC
This report has been filled here: https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/139526 "Binary package hint: f-spot F-spot is urldecoding the parameter for the file that its trying to get imported, if you have a file called '~/picture%202.png', and drag & drop it over F-Spot window, it will try to open '~/picture 2.png' instead, an return a error about not found file. I've included a screenshot of the error message. " http://launchpadlibrarian.net/9275937/fspot.png
*** Bug 499505 has been marked as a duplicate of this bug. ***
Merging comment by Bengt from Bug 499505: Just some more information on this bug from the mail list. --- The problem: If I convert some RAW files (with Bibble or any other RAW converter) I save them in the same directory as the RAW files. To get them into F-Spot I reimport all files in this directory. If I have any photo in there with spaces in the filename which is imported in F-Spot yet F-Spot tries to reimport this photo, too. The result are two photos in F-Spot refering to the same file. That's the problem. > And about the %20% things: were did you see that pattern ? in the 'Name' > on the left sidebar ? or elsewhere ? (I agree, the left sidebar is > wrong). Yes, in the left sidebar. But if I reimport the photo, the new one shows it right, without %20. > I suspect an encoding issue, does this command returns something ? > > select l.id, l.uri, r.uri from photos as l, photos as r where l.uri LIKE > r.uri AND r.id != l.id; Yes, it returns 20-30 rows approximately. (I have about 6000 photos in my photos.db.) Does this query returns all the duplicates? Matching the URI but not matching the ID?
The steps to reproduce this issue: (copied from the other, duplicate bug) 1) Importing files with spaces in the filename. No problem. They are all right. 2) Restarting f-spot. Now F-Spot uses those %20 as spaces (in the sidepane on the left). 3) Now, if I want to import new files of the same folder (/home/paul/Photos/2007/11/25/ for example), f-spot does not recognize that the file stored there is in the database yet and it is imported another time. So I have "test with spaces.jpg" and "test%20with%20spaces.jpg" in the database deirecting to the same URL ("/home/paul/Photos/2007/11/25/test with spaces.jpg").
Note, there are 2 issues here. 1. Importing a filename that has "%20" in the file name. Like "pic%202.jpg" and f-spot reading that as "pic 2.jpg" 2. Importing a filename like "pic 2.jpg", and after a second opening of f-spot, f-spot's name field changing to "pic%202.jpg. The second bug has been confirmed. In f-spot code, checking photo.Name for a given photo will in fact return "pic%202.jpg" in a string. I verified this while I was writing an extension for bug 342138, and printing out the filenames in a dialog. (This information for the latest svn version, version 3461)
(In reply to comment #4) > The second bug has been confirmed. > In f-spot code, checking photo.Name for a given photo will in fact return > "pic%202.jpg" in a string. Yes, two bugs, but I'd say the second one is only a visualization issue. The blocking problem is that on import f-spot doesn't escape uri special characters.
Well, it is only a visualization issue for end users. But it is a more serious issue than that, because the representation of a photo's name is incorrect in the code. For somebody like me, who is trying to write an extension that will last a while, it is more than just a visualization issue. The second problem may not be a blocking problem though, I'll accept that.
(In reply to comment #6) > But it is a more serious issue than that, because the representation of a > photo's name is incorrect in the code. For somebody like me, who is trying to > write an extension that will last a while, it is more than just a visualization > issue. I misunderstood. Photo uri is correct, while, yes, photo name is wrong. It should be an easy thing to fix but I can't get out of it :) Maybe I'll have a look this evening.
Created attachment 106617 [details] [review] proposed fix Here's a patch for this. this patch need some more testers before being committed
I tested the patch. It does not apply automatically on latest svn, the first hunk has to be patched manually. The patched F-Spot works almost all fine with this patch. Images with '%20' in its filename are imported fine and not reimported twice if they are stored yet. The only problem is that "delete from drive" does not work yet. The images are just not deleted.
I independently noticed that bug yesterday, but didn't find this report, but did the discussion and patch in bug 433829. I fixed it by properly escaping % in file names as well.
Created attachment 119631 [details] [review] quote % in file names
thanks martin. your patch works fine on import, but this bug also affects the infobox (maybe ImageFile?), where image dimensions are not displayed for images containing %.
Hm, that works fine for me, though. I tested it with both "%32" in directory name and "%32" in file name. The info box correctly says "foo%32bar.jpg".
does it correctly displays photo size (1024x768)?
Oh, indeed that doesn't work, it's shown as 0x0. Sorry, missed that. I haven't debugged why that happens. On the plus side, "delete from drive" does work here.
should be fixed properly on trunk. could you please test this ?
mmm, not sure it's the same bug
Created attachment 139206 [details] [review] patch against git master to escape % chars correctly I've just run into the same problem: f-spot --import /tmp/test%3Atest results in an error: System.IO.FileNotFoundException: Could not find uri "file:///tmp/test:test/dsc_0001.nef". at Gnome.Vfs.VfsStream..ctor (System.String text_uri, FileMode mode, Boolean async) [0x00000] at Gnome.Vfs.VfsStream..ctor (System.String uri, FileMode mode) [0x00000] at (wrapper remoting-invoke-with-check) Gnome.Vfs.VfsStream:.ctor (string,System.IO.FileMode) at FSpot.ImageFile.Open () [0x00000] at FSpot.Tiff.TiffFile..ctor (System.Uri uri) [0x00000] Error importing /tmp/test%3Atest/dsc_0001.nef Not aware of this bug report I've also created a very similar patch (as already attached here) against current git master. It would be great if it could be applied upstream, too.
Tested and merged: commit a76f6c3a4adf4613ad6a610e2a8d5ffc76f28d85 Author: Christian Krause <chkr@plauener.de> Date: Fri Jul 31 23:03:31 2009 +0200 escape % when converting a file name into an URI From the merge request [1]: > → State changed from Open to Merged > > Uri escaping uses % to escape characters (as opposed to a backslash > for command line arguments). As an example: # gets turned into %23. > Escaping % is needed. > > It’s not nice that we include our own escape function, but the fix > by Christian is correct, merging. > > It might be the case that there’s a different alternative to replace > our escaping function, but that shouldn’t block this fix in the > meantime. [1]: http://gitorious.org/f-spot/mainline/merge_requests/1080