Import of photos to be COPIED does not work correctly

Bug #797117 reported by Zordid on 2011-06-14
This bug affects 7 people
Affects Status Importance Assigned to Milestone
shotwell (Ubuntu)

Bug Description

Binary package hint: shotwell

I try to import photos into my library, put the new photo (a sinlge picture!) into a temp folder in my home directory.
Choose "import folder", select the folder and THEN choose "Copy" instead of link.

=> the picture is not copied but stays where it is! When I open Nautilus using the context menu on this picture, the temp folder is shown!

Tough bug! What happens when I choose to copy??? Is that ignored? Is it because it is a single picture??

Maybe this is important:

I have a Solid State Disk with my home on it. But large amounts of data (like my pictures!) are stored on the second hard disk drive. So my "Pictures" folder is a symlink to a different partition!! ~/Pictures -> /homehdd/myuser/Pictures

Maybe that is causing the trouble??

Also: copying the picture into the correct destination folder does not trigger the watch feature correctly! Shotwell does not realize there's a new picture!

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: shotwell 0.9.3-0ubuntu0.1
ProcVersionSignature: Ubuntu 2.6.38-10.44-generic
Uname: Linux 2.6.38-10-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue Jun 14 12:19:05 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427)
 PATH=(custom, user)
SourcePackage: shotwell
UpgradeStatus: No upgrade log present (probably fresh install)

Zordid (zordid-gmx) wrote :
Sebastien Bacher (seb128) wrote :

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

Changed in shotwell (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Eric Gregory (eric-yorba) wrote :

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?

Sebastien Bacher (seb128) wrote :

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)

Dan Blum (dan-blm) wrote :

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

Adam Dingle (adam-yorba) wrote :

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.

daisy stanton (stanton-r) wrote :

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)


Adam Dingle (adam-yorba) wrote :


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 ( 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.

mackiecc (tiloem) wrote :

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!

mackiecc (tiloem) wrote :

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?

Adam Dingle (adam-yorba) wrote :

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

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 .

b (ben-ekran) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers