Import of photos to be COPIED does not work correctly

The same seems to happen when importing a directoy on 0.10.1 in oneiric

I'm a bit confused on what to do with this ticket, there's so many things going on here. Is the issue importing when the library folder is a symlink to a different partition? Or is it importing from a folder?

The issue is what you import a directory from shotwell it will ask you if you want to copy or import without copy, if you select "copy" it doesn't actual copy those (you can check by telling shotwell to open the directory for the photo after the import, it will open the directory you asked to import not one in the shotwell library)

I have a similar issue using shotwell 11.2. Cannot import photos from folder. Gnome and gimp work fine.

This behavior is expected if the photos you're importing are already in the library directory: in that case Shotwell won't copy them (and, in recent versions of Shotwell, won't ask you whether you want the photos copied). So if Shotwell doesn't seem to be copying your photos, you should check your library directory setting in Shotwell's Preferences dialog. Perhaps it's mistakenly set to your home directory, in which case Shotwell will never copy photos imported from your home directory or any of its subdirectories.

I also just got confused by this. :)

Here's my use case: I like how Shotwell puts my photos into datestamped directories, so if I have a folder of photos I've e.g. downloaded from somewhere (rather than imported from my own camera), I like to be able to import with copy to get the Shotwell directory structure. I can then delete the directory from which I imported.

When I tried this the first time I was confused not to see the prompt about symlinks/copies. After I found this issue it made sense, but perhaps it would be nice if a dialog could inform the user about what's going on? (e.g.: "Since you're importing from a subdirectory of your library, Shotwell will create symlinks to these files instead of copies. If you'd like to copy instead, move ${IMPORTDIR} outside of ${LIBDIR}" ... or something along those lines)

Thanks!

Daisy,

first, to be clear, there are no symbolic links involved in this situation. Shotwell simply imports the photos in question into its database in their current filesystem locations. (Shotwell will never, in fact, create a symbolic link). In earlier versions of Shotwell we referred to this behavior as "linking", but people found that confusing so we now call it "importing in place".

I can understand that it may not have been obvious why the copy/no copy dialog didn't appear for you. I've created a ticket upstream (http://redmine.yorba.org/issues/4502) for possibly displaying a dialog as you suggest. Also, I think that before long we may display a set of options on every import, and once we're doing that we could simply disable the copy option in this situation; that might make things a little clearer.

I have the same issue with shotwell 0.11.4.
For me it happened after I deleted all photos manually from the shotwell folder (because there was no proper folder structure) and then reimported the same photos from my backup to let shotwell recreate a proper folder structure. Photos were imported but linked instead of copied.
Thanks for working on it!

Sorry for the wrong entry. My problem actually refers to

bug #813191
"When importing photos that are marked as missing, Shotwell always imports them in place even though I ask it to copy the photos"

Could bugs #797117 and #813191 actually be the same?

The bugs are not the same. This bug (797117) does not involve missing photos, and as I explained in comment #6 it's not actually a bug according to the Shotwell designers. It's simply how Shotwell works, though we could possibly display more helpful messages to explain what's going on (as proposed in http://redmine.yorba.org/issues/4502).

Bug #813191 involves missing photos. It's a tricky edge case, and Shotwell's current behavior is possibly not ideal. The corresponding upstream ticket is http://redmine.yorba.org/issues/3875 .

This looks a lot like a bug I just reported in a newer version of shotwell (0.18.0) under Trusty: Bug #1458085