---- Reported by adam@yorba.org 2010-11-14 14:22:00 -0800 ----

Original Redmine bug id: 2824
Original URL: http://redmine.yorba.org/issues/2824
Searchable id: yorba-bug-2824
Original author: Adam Dingle
Original description:

A suggestion on the Shotwell mailing list from Vivien Didelot:

When the date of a photo is changed, the file is not moved to its correct
path. e.g. a photo with a date of 2004/01/01 will be stored in
/somewhere/2004/01/01/my-pic.jpg.

After having change the date to 2007/12/12, the photo will still be in
/somewhere/2004/01/01/my-pic.jpg.

Related issues:
related to shotwell - Feature #1940: Adjusting timestamp on picture in
Shotwell doesn't move i... (Fixed)
related to shotwell - Feature #2170: reimport/rearrange existing photos in
library directory (Open)
related to shotwell - Feature #3549: allow photo directory structure to
include event name (Open)
duplicated by shotwell - 5558: Pictures are not moved in the correct
folder after ajusti... (Duplicate)



---- Additional Comments From shotwell-maint@gnome.bugs 2013-09-16 01:11:00 -0700 ----

### History

####

#1

Updated by Shantanu - almost 3 years ago

I'd second for this option as I was just searching for this very same thing
after facing this issue.

A query is that right now I am using 0.7.2. When it is implemented in a newer
version, will this work on my existing library? Right now I see that most new
options are implemented to work on an event. e.g. once this feature is
implemented, after that if I change a photo's timestamp then it will change
its location as well. But what about existing pics in the library that are
sitting in the incorrect position? If you haven't thought about it, please
keep it as a concern while implementing and provide an option to scan/re-scan
the existing library and redo the organization format acc. to existing
metadata.

This particular thing would also be useful when considering that there are a
number of other tickets pertaining to file-folder custom naming/organization
pending and this option of rescanning/reorganizing existing files will be good
in those scenarios as well.

####

#2

Updated by Shantanu - almost 3 years ago

Just noticed that http://trac.yorba.org/ticket/2170 is already created to
satisfy the option that I mentioned in my comment. You guys are thorough :)

Looks like Shotwell is going to be my main photo manager soon enough..

####

#3

Updated by Adam Dingle over 2 years ago

  * **Priority** set to _High_

#3419has been marked as a duplicate of this ticket.

####

#4

Updated by Adam Dingle over 2 years ago

  * **Target version** set to _0.10_

####

#5

Updated by Adam Dingle over 2 years ago

  * **Target version** deleted (<strike>_0.10_</strike>)

####

#6

Updated by Andrew McNabb about 2 years ago

  * **Description** updated (diff)

Is this a duplicate of 2170?

####

#7

Updated by Adam Dingle about 2 years ago

@Andrew: It's true that if we implement #2170 and choose to make it fully
automatic then the behavior described here will happen automatically. But I'd
rather keep this as a separate ticket, because it involves a specific case
(the Adjust Date and Time command) which we might address separately.

####

#8

Updated by Andrew McNabb about 2 years ago

  * **File** enforce-directory-pattern.patch added

I am attaching a patch that begins work on implementing this feature. It's my
first time coding in Vala or glib, so I'm sure that there are some mistakes.
Feedback is welcome.

I'm think the logic is mostly right. The main area where I'm pretty sure that
I'm wrong is with all of the different kinds of secondary files. The patch
currently moves the master file, but it ignores editable files, raw developer
files, backing files, etc. The reason for this omission is that I don't
understand exactly what and where each of these are, so I'm not sure which
files actually should be moved. With some clarification, I think it wouldn't
be hard to fix.

Anyway, it's at least a start, and hopefully it paves the way for some related
features such as issues #2170 and #2824.

####

#9

Updated by Adam Dingle about 2 years ago

  * **Status** changed from _Open_ to _Review_
  * **Target version** set to _0.12_

Thanks the patch. Lucas, please review and/or comment.

####

#10

Updated by Lucas Beeler about 2 years ago

  * **Status** changed from _Review_ to _Open_

Hi Andrew,

First of all, I'm very impressed by your patch. You put a new checkbox into
the preferences dialog exactly where we would've put it, and you figured out
the Configuration API. This is really great and your patch is a good start.
Two comments about moving forward, in order of priority:

(i)

When the master file is moved, all of the auxiliary files (editable, RAW
developments, etc.) absolutely must be moved along with it. When we were
developing features like launching external editors, RAW+JPEG pairing, and
switching RAW developments, we never considered the possibility that the
master file and its auxiliary files might exist in separate directories, so
all of our code is written assuming that the invariant "all auxiliary files
shall exist in the same directory as the master file" is true. Breaking this
invariant could have far-reaching consequences that are hard to track down, so
the auxiliary files must be moved with the master. That said, I know it's hard
to figure out how the auxiliaries are named and how many of them there can be
(especially in edge cases such as when the sibling JPEG of a RAW+JPEG pair has
been edited in an external editor). The Shotwell architecture doc, available
here:
http://redmine.yorba.org/projects/shotwell/wiki/ShotwellArchitectureOverview,
discusses some of this and we Shotwell engineers are happy to answer any
specific questions you might have.

(ii)

It may be unclear for some users exactly what "enforcing" the directory
pattern entails. Is is a big, ugly operation? No, all we're really talking
about here is moving files, so I'd prefer that the preferences choice be named
"Move files to enforce directory pattern."

Cheers,

Lucas

####

#11

Updated by Lucas Beeler about 2 years ago

Hi Andrew,

As you can (hopefully) tell from using the app, two of the things that we
really value in Shotwell are simplicity and predictability. For example,
Shotwell doesn't have a lot of UI chrome compared to, say, F-Spot or Picasa
and most of the time Shotwell does what you expect it to do.

With these values in mind, we've just had a product management meeting about
this feature and have decided that there should be no additional checkbox in
the preferences dialog to turn the "enforce structure" behavior on and off.
Instead, the spec should be as follows:

(i)

There exist two kinds of files in the Shotwell library: those that are
participating in the directory structure created by Shotwell and those that
are not (such as photos that the user dragged into his or her ~/Pictures
folder that were imported automatically). Today, we do not move auto-imported
files into the Shotwell-managed directory structure because we feel that if
the user has dragged a photo to a certain location that he or she has made a
positive decision to place the file there and that we shouldn't interfere with
that.

(ii)

Given (i), files that are not participating in the Shotwell directory
structure are never moved, even when their date and time changes.

(iii)

Given (i), files that are participating in the Shotwell directory structure
are always moved when their date and time changes.

The removal of the "Enforce..." checkbox widget in the preferences dialog
keeps the Shotwell UI simple, and we think that the behavior above is pretty
much what users expect to happen.

Cheers,

Lucas

####

#12

Updated by Adam Dingle about 2 years ago

Right. To be clear, we can tell whether a file is participating in the
Shotwell structure by computing the directory path it would normally be
assigned to based on the photo's date/time **before** the user adjusted it. If
the file actually **is** in that directory, then case (iii) applies and we'd
like to move the file.

####

#13

Updated by Andrew McNabb about 2 years ago

Thanks for the kind words and feedback. I have a few followup
thoughts/questions, which I will identify by comment number.

#10.(i)

I anticipated this issue, and the only reason that I didn't get to it was to
avoid wasting time if I was taking the wrong approach on a fundamental level.
It will probably take me some time to make sense of all of the different types
of auxiliary files, but the general idea is fairly straightforward.

#11.

I can't speak for other users, but I can give some detail about my own
situation. I have a preexisting Pictures directory, and while I would
appreciate a default of keeping my files where they are, I would like to be
able to give some way to trigger Shotwell to start managing a particular file
or set of files. Would I have to drag all of these files out of the Pictures
directory to some Pictures2 directory and then import Pictures2? Would there
be any way to identify which files are not currently participating in the
Shotwell structure so that I would know which ones to drag out and reimport?

#12.

On a coding level, I was able to find a trigger that's called when the
exposure timestamp is changed, but does the Alteration object have access to
the old value? Or is there a better way to find out from the notify_altered
method what the old timestamp was? I could imagine a number of inelegant
workarounds, but I'm wondering whether there is an obvious way.

####

#14

Updated by Adam Dingle about 2 years ago

Regarding comment 11, what you're really looking for is an implementation of
ticket #2170 (as we discussed above). If you want to work on that we'd be very
happy to have your help!

Regarding comment 12: Lucas, do you have any ideas about this? Should we test
whether the photo is in place in the directory structure even **before**
renaming it, and then pass that boolean value somehow to the code that will
move the corresponding files?

####

#15

Updated by Andrew McNabb about 2 years ago

I guess I see this as a sort of prerequisite or first step of issue #2170.
It's easier to try to start with renaming with an eye toward expanding this
forward more generally.

####

#16

Updated by Adam Dingle about 2 years ago

Agreed.

####

#17

Updated by Andrew McNabb almost 2 years ago

I've been thinking about this the last few days. If some files are
"participating" in the directory structure, and some are "non-participating",
and if participating files behave differently than non-participating files,
then there has to be some visible indicator of whether a file is participating
or non-participating. Without an indicator of some sort, auto-renaming would
appear to be a mystical and/or unreliable feature.

How do you envision the user interface for indicating participating vs. non-
participating? Or am I missing something?

####

#18

Updated by Adam Dingle almost 2 years ago

Andrew: I don't think this will be too confusing. As far as the user interface
goes, every photo (whether "participating" or not) should move to a new event
when its timestamp changes, so there will be no confusion there. That's a
separate ticket, though (#1940). At the file system level, as I suggested
before I think we probably just want to move "participating" photos,
especially since non-participating photos might be on a different filesystem
(in which case moving them could be expensive).

If you like, after the timestamp is adjusted we could display a dialog which
asks the user whether to move photos. I probably wouldn't want to offer that
choice for photos on other filesystems, though, and then there's the tricky
question of what to do if some photos in a single rename operation are in the
library and some are on a different filesystem. Maybe we can simply implement
the automatic moving of already participating photos as I suggested and see if
that's good enough.

####

#19

Updated by Andrew McNabb almost 2 years ago

I'm glad I'm asking questions because I think it's helping me get a better
picture of what's envisioned. Just to make sure I now understand:

1) A file is "participating" if it's in the library location.

2) A file is "non-participating" if it is outside the library location.

3) All files in the library location will always be moved in accordance with
their timestamps and the directory structure.

Is that all correct? To clarify my confusion: I had previously understood
"participating" files to be those whose timestamps matched the directory
structure.

So, if all files in the library location are always moved to match the import
structure, it would probably be good to give some warning upfront in case a
user has a custom directory structure within the library location. In this
case, the user should keep this custom directory outside the library location,
right? An initial warning would help make sure that there aren't any big
surprises.

####

#20

Updated by Adam Dingle almost 2 years ago

Andrew: as I mentioned in comment 12 above, a file should be "participating"
if it is in the directory it would normally be assigned to based on the
photo's date/time. For example, let's imagine a photo was taken at 7:00 AM on
July 4th, 2011, and that the user's directory structure is Year/Month/Day (the
Shotwell default). Let's also imagine that the library directory is
~/Pictures.

  * If the photo is in ~/Pictures/2011/07/04, it is participating.
  * If the photo is in ~/Pictures/mycat/2011, it is not participating (though it is in the library directory).
  * If the photo is in /media/cdrom/mycat/2011, it is not participating.

Clear enough? Given this, I think that moving participating photos makes
perfect sense. I also think it won't be too surprising if we don't move non-
participating photos when their timestamp changes. (Users might indeed want to
move non-participating photos into the directory structure, but that's a
separate project (#2170).)

####

#21

Updated by Andrew McNabb almost 2 years ago

"as I mentioned in comment 12 above, a file should be "participating" if it is
in the directory it would normally be assigned to based on the photo's
date/time."

That's what I thought at first, but I guess I misunderstood comment #18.
Thanks for the further clarification.

The problem I see is that there is no way for a user to know whether or not a
photo in the library directory is participating. This makes auto-renaming seem
capricious to the user.

####

#22

Updated by Andrew McNabb almost 2 years ago

I was just wondering whether there are any new updates about the intended
behavior. I haven't put any time into looking at the code because I don't have
a clear vision about how the user interface will feel. By the way, I'm happy
to be convinced, I just haven't been yet. :)

####

#23

Updated by Adam Dingle almost 2 years ago

Andrew,

I think our proposal is pretty clear. In general, photos' filesystem paths
aren't very visible in the Shotwell user interface, so I personally don't feel
there's a compelling need for the user interface to indicate whether a photo's
path matches the directory pattern or not. I wouldn't necessarily be opposed
to some such indication in the Advanced Properties dialog, but nor do I feel
like we have to have one at this stage. If you can think of a better approach
and have a counterproposal, we're all ears.

####

#24

Updated by Andrew McNabb almost 2 years ago

Under the proposed behavior, a file will be moved if it is currently
participating but will not be moved if it is not participating. From the
user's perspective, it will seem like a bug when a photo's time is changed but
the file is not moved. Whether or not a file is moved is a behavior that is
entirely unpredictable by the user. At some future point when event names can
be used for renaming, the behavior will seem even more unpredictable.

I can't speak for all other users, but if Shotwell is going to rename files, I
want to know what it's going to do. I personally would want it to either 1)
completely manage all filenames, or 2) give some visible indication of which
filenames are nonparticipating so that if there's a mistake I can fix it.

####

#25

Updated by Adam Dingle almost 2 years ago

  * **Target version** deleted (<strike>_0.12_</strike>)

####

#26

Updated by Adam Dingle about 1 year ago

  * **Target version** set to _0.14.0_

I'd really like to see this implemented for 0.14. I need to adjust dates/times
on a bunch of my photos and I'd like them to end up in the correct folders.

####

#27

Updated by Jim Nelson 11 months ago

  * **Category** set to _library-mode_

####

#28

Updated by Jim Nelson 11 months ago

  * **Target version** changed from _0.14.0_ to _0.15.0_

We'll take a look at this for 0.15.

####

#29

Updated by Jim Nelson 8 months ago

  * **Target version** changed from _0.15.0_ to _0.16.0_

####

#30

Updated by Jim Nelson 6 months ago

  * **Target version** deleted (<strike>_0.16.0_</strike>)

####

#31

Updated by mjob _ 2 months ago

I'd like to see this feature in shotwell as well. I also can test the feature
if this is needed. Does anybody work on this?



--- Bug imported by chaz@yorba.org 2013-11-25 21:48 UTC  ---

This bug was previously known as _bug_ 2824 at http://redmine.yorba.org/show_bug.cgi?id=2824
Imported an attachment (id=261874)

Unknown version " in product shotwell. 
   Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution