Imports all photos to the root of the home directory

thanks for the report, i cannot reproduce this with jaunty as well, in the presence of the Photos folder f-spot imports the photos to that one, if there's no such directory it fallbacks to the home directory (and there's already a bug about that) could you please try to get a f-spot log with : f-spot --debug &> f-spot.txt reproduce the issue and attach the resulting file to the report? thanks in advance Jean.

I can confirm that I have the same issue with Jaunty beta.

when I connect my camera (Canon digital IXUS 80 IS) to my desktop, f-spot is not launched.
I ran f-spot using the command ``f-spot --debug &> f-spot.txt'' and attempted to import manualy by
selecting import from the menu then the camera.
I got an error saying:
>Error connecting to camera
>Received error "Could not lock the device"
>while connecting to camera

I then opened the camera from nautilus under computer and was invited to open camera using f-spot
this time the import did proceed, but as the bug states, imported all my photos into the root of the home directory and not the Photos folder like in previous releases.

I have attached the f-spot log, if any other information is required, I would be happy to help
Alistair

In order to be able to reproduce it correctly, I removed any trace of f-spot:
$ rm -rf ./.gnome2/f-spot

And then I launched f-spot with Nautilus button. And as you can see on the print-screen destination folder selected is "Jlhenry" (my username and the root of my user directory: /home/jlhenry) and not "Photos".

After having imported some photos, I go to Edit->Preferences and default importation folder is "Photos".

I can confirm that I have a "Photos" folder located in my root (/home/jlhenry/Photos):
drwxr-xr-x 2 jlhenry jlhenry 4096 2009-04-04 09:10 Photos

Strange...

I can confirm this, after upragding to jaunty f-spot imports the photos into ~ instead of ~/Photos/month/day
Worked great in 8.10, Photos dir is present.

I can confirm this behaviour as well. I upgraded to 9.04 today, from 8.10. Imported photos goes into my home directory, and not into Photos. F-spot is configured to import into "Photos", and the folder does exist. Very annoying.

I can confirm this, too. In intrepid f-spot imported to the configured directory, since upgarde to jaunty it imports direcly into my home-directory without any subdirectory-structure. I can change the import directory in the import dialog, but f-spot does not remember that.

Duplicate bug:

https://bugs.edge.launchpad.net/ubuntu/+source/f-spot/+bug/353989

The problem was caused by ubuntu_importer-targetdir-selector.dpatch:

+ if (File.Exists(FSpot.Global.PhotoDirectory))

According to Microsoft's C# documentation, File.Exists will always return false when passed a directory path. It should be calling Directory.Exists. Having made this change locally, the bug is fixed for me (by default it chooses the directory set in my config and uses YYYY/MM/DD subdirectories).

So really, I'm not sure how this could ever have worked, or why it couldn't be reproduced. Pedro, are you sure:

- that you are actually using f-spot from ubuntu
- that you are not taking any action to select an import directory
- that the image files are being placed in YYYY/MM/DD subfolders

I have attached a patch for karmic. I am more than happy to do so for jaunty if it has any chance of getting uploaded and if someone explains what the new version number should be.

I confirm I have this buggy behaviour since upgrade to Jaunty ...

The proposed fix works for me too, so I think it should be provided through updates, since importing pictures from a digital camera is a major feature.

Not totally unrelated question ... does somebody know why F-Spot actually provides *2 slightly different dialogs* for the same importing feature (the one accessible from File -> Import ... which works perfectly, and the one that pops up on sd card insertion which is currently broken) ? This is a bit confusing.

Graham Bleach, the Jaunty current version number is 0.5.0.3-1ubuntu6

It'd be great if you could upload the f-spot.debdiff for Jaunty! If it worked for jaile I'm sure it should work for the rest of us.

Thank you.

I've put a fixed version in my PPA: https://edge.launchpad.net/~mwhudson/+archive/ppa (not sure if I chose an appropriate version for my upload though, I always forget the details of that bit...)

Confirmed that Michael Hudson's package for jaunty works for me.

I also confirm that Michael Hudson's package for Jaunty works for me.

Thank you so much Michael!

Now does anyone have a script to clean up the mess yet?

I'll third confirmation that Michael's fix worked for me, and second a request for a script to clean up the hundred or so photos sitting in my home directory completely unorganized.

Here's an attempt at a clean up strategy. Note that I don't have any incorrectly placed photos on this computer, so the following is all untested. You should only proceed if you understand what the commands are doing.

Move the relevant photos (probably in ~/2009) to the ~/Photos directory. Make sure you don't accidentally overwrite any existing photos or directories (go back and forth between the two directories, copying photos, in Nautilus for example). There's probably an easy automated command line solution for this, but I leave that to someone else (fiddle with 'find ~/2009', 'mkdir -p', and 'cp').

Now update the F-Spot database:

martijn@michelle:~$ sqlite3 .gnome2/f-spot/photos.db
SQLite version 3.6.10
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> update photos set uri = replace(uri,'file:///home/martijn/2009/','file:///home/martijn/Photos/2009/');
sqlite> update photo_versions set uri = replace(uri,'file:///home/martijn/2009/','file:///home/martijn/Photos/2009/');
sqlite> .exit
martijn@michelle:~$

Of course, if you have a localized or customized location for ~/Photos, use that in the above instructions. And use your own home directory.

This can all be easily combined into a script that does some safety checks and reports back to the user on its results by whoever wants to sit down for it.

Aha, interesting. I'll get this done.

For me all photos ended up in my home directory without sub-directories for dates. So after moving all my photos to the right place a slight modification of Martijn's database update was needed. Note that all the filenames for my photos start with "dsc". I hope this is useful to someone.

chris@k9:~$ sqlite3 .gnome2/f-spot/photos.db
SQLite version 3.6.10
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> update photos set uri = replace(uri, 'file:///home/chris/', strftime('file:///home/chris/Photos/%Y/%m/%d/', time, 'unixepoch')) where uri like 'file:///home/chris/dsc%';
sqlite> update photo_versions set uri = replace(uri, 'file:///home/chris/', strftime('file:///home/chris/Photos/%Y/%m/%d/', (select time from photos where photos.id = photo_versions.photo_id), 'unixepoch')) where uri like 'file:///home/chris/dsc%';
sqlite> .exit
chris@k9:~$

I have a Python script that fixes up the mess. It shouldn't have any dependencies other than Python itself. I've only tested with Python 2.6, but I don't know of any reason 2.5 wouldn't work (before 2.5 the sqlite3 module won't be available).

Features:

1. Moves files to [target-dir]/YYYY/MM/DD for the date of the photograph itself, as is f-spot's current correct behaviour, creating these directories where necessary

2. Target dir need not be ~/Photos but can be arbitrary

3. Updates the photos and photo_versions tables in the f-spot database correctly (as far as I can tell anyway) both for original versions and modified versions.

----

Usage: fix-fspot.py [correct target directory] [files...]

Example usage:

python fix-fspot.py ~/Photos ~/img_0001.jpg ~/img_0002.jpg

Move ~/img_0001.jpg and ~/img_0002.jpg to the correct location under ~/Photos and updates the f-spot database appropriately.

In case of corruption, your original database will be copied to ~/.gnome2/f-spot/photos.db-[TIMESTAMP] each time this runs

----

My run of this was:

python fix-fspot.py ~/Photos ~/*.{cr2,jpg}

but of course you will want to construct your own command line.

Oh, and in the event it's important to anyone, here's a version of fix-fspot.py with licencing information

Final comment: if you have any extra files around in your homedir that you want moved but which f-spot's database doesn't know about (in my case .ufraw files) you will have to move them by hand: the script will abort if you ask it to do something with a file f-spot has no record of.

This bug was fixed in the package f-spot - 0.5.0.3-5

---------------
f-spot (0.5.0.3-5) unstable; urgency=low

  [ Tim Retout ]
  * Remove self from Uploaders.

  [ Iain Lane ]
  * debian/patches/ubuntu_importer-targetdir-selector.dpatch: Swap File.Exists
    for Directory.Exists as we are checking for the presence of a directory
    and File.Exists returns False if called on a directory, even if it does
    exist. The effect of this bug was that the import dialog defaulted to
    the user's home directory despite any configuration that may be in place.
    Thanks to Graham Bleach. (LP: #354264)
  * debian/rules: Remove gio-sharp-unstable.pc from the package. f-spot is not
    the authorative source for gio-sharp and therefore should not make it
    available to others to use. (Closes: #532943)
  * debian/control: Bump standards-version, no changes

  [ Jo Shields ]
  * debian/patches/debian_dont_link_libmono.dpatch:
    + Small patch to prevent libmono0 linkage in F-Spot's unmanaged
      libraries. This should save dependency chain space

 -- Iain Lane <email address hidden> Fri, 10 Jul 2009 11:37:03 +0100

Apologies but I've read through and not sure if this fix will be released for Jaunty or whether we should apply the patch in the thread. Please can you confirm.
Thanks,
Russ.

It is fixed in Karmic. Needs SRU for Jaunty if you want to have it fixed there.

Unluckily it looks like the fix will only become effective in karmic
koala ...

Stefan

Am Donnerstag, den 16.07.2009, 20:01 +0000 schrieb Russell Wing:
> Apologies but I've read through and not sure if this fix will be released for Jaunty or whether we should apply the patch in the thread. Please can you confirm.
> Thanks,
> Russ.
>

Ummm... this is a regression that makes F-Spot close to useless for novice users... :-(

I think the Ubuntu project needs a process that imports well tested fixes from individuals' PPAs. That would make this sort of thing easy to release a fix for...

Can we have an explanation for what the triaging as "Low" for Jaunty means in practical terms?

The effect of the bug is that people who use f-spot and Jaunty throughout the Jaunty lifetime will have every single one of their imported photos dumped into their home directory. Not into subdirectories of their home directory, an entire six months (at least) worth of photos all directly under ~/

This will, unless they run my script, never be repaired (unless the karmic fixed package actually moves existing photos, I don't see any hint that it does), meaning that, if they, for example, back up ~/Photos believing it contains their imported photos as the program informed them it would they will miss all photos imported during the Jaunty lifecycle.

It's not a data loss bug in and of itself, but it's something of a serious data integrity bug.

So does "Low" mean, practically:

(a) the effects of the bug appear minor to Ubuntu developers?
(b) the Ubuntu developers have no opinion about the effects of the bug, but do not intend to fix it in Jaunty?
(c) the Ubuntu developers have no opinion about the effects of the bug and will not prioritise a fix but would accept one if the community organises the SRU as far as possible?

Is there any way we can get the fixed version into the official repos? This is frustrating a lot of people.

Mary Gardiner wrote on 2009-08-19:
> Can we have an explanation for what the triaging as "Low" for Jaunty means in practical terms?
<snip>
> It's not a data loss bug in and of itself, but it's something of a serious data integrity bug.

Unfortunately, for me, this *was* a data loss bug.

I noticed a whole bunch of jpg files in my home directory and thought "hey, they shouldn't be there, I must have file-copied them here from my camera as I sometimes do. I can see f-spot has them and I know it keeps stuff in ~/Photos so I'll just delete them... hey, why aren't they showing up in f-spot anymore???".

They had already been deleted from the camera, and my nightly backup hadn't yet run. AUGH!!! Bye-bye photos.

OK, so I really, really should have checked it all further first, and the data loss was due to my own haste and stupidity in addition to this bug, but still...

Chris Dunlop: you don't say if this was a recent problem, but if it was some or all photos may be recoverable from your memory card. photorec (/usr/sbin/photorec, once you install the testdisk package) is a good tool for this.

You're perfectly right that it's a major problem with the package. The triaging as 'low' remains unexplained.

Mary, thanks for your hint. Unfortunately for me the problem occured about a month ago and I was removing the files off the camera in preparation for an overseas trip (hence my highly unfortunate haste) from which I've just returned, having now re-filled the memory card with new photos. It was in using f-spot to download the new photos that I noticed they went into the home directory and I started investigating, and hence how I ended up here!

I've now installed the Michael's fixed PPA version of f-spot so I'm ok myself, but I'd hope the Ubuntu crew reconsider the 'low' classification in light of this data loss to help avoid having someone else losing irreplaceable photos.

A simple workaround is to manually select the folder (pick "Other" from the menu, and browse to your "Photos" folder. After doing this, f-spot will put things correctly in the hierarchy. (But I'm upgrading to Karmic now, so hopefully this will no longer be necessary for me)

Thank you for taking the time to report this bug. This issue has been fixed in newer versions of Ubuntu, and Jaunty is EOL, so I am closing this bug task.