move photo file to new path after date/time adjustment
Submitted by Adam Dingle
Link to original bug (#717029)
Description
---- 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 (closed): reimport/rearrange existing photos in library directory (Open)
- related to shotwell - Feature #3549 (closed): 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
Comment 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.
Comment 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..
Comment 3
Updated by Adam Dingle over 2 years ago
- Priority set to High
#3419has been marked as a duplicate of this ticket.
Comment 4
Updated by Adam Dingle over 2 years ago
- Target version set to 0.10
Comment 5
Updated by Adam Dingle over 2 years ago
-
Target version deleted (
<strike>
_0.10_</strike>
)
Comment 6
Updated by Andrew McNabb about 2 years ago
- Description updated (diff)
Is this a duplicate of 2170?
Comment 7
Updated by Adam Dingle about 2 years ago
@Andrew: It's true that if we implement #2170 (closed) 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.
Comment 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 (closed) and #2824 (closed).
Comment 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.
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
Comment 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
Comment 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.
Comment 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 (closed).(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.
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?
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.
Comment 14
Updated by Adam Dingle about 2 years ago
Regarding comment 11, what you're really looking for is an implementation of ticket #2170 (closed) (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?
Comment 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 (closed). It's easier to try to start with renaming with an eye toward expanding this forward more generally.
Comment 16
Updated by Adam Dingle about 2 years ago
Agreed.
Comment 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?
Comment 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.
Comment 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:
-
A file is "participating" if it's in the library location.
-
A file is "non-participating" if it is outside the library location.
-
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.
Comment 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 (closed)).)
Comment 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.
Comment 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. :)
Comment 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.
Comment 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.
Comment 25
Updated by Adam Dingle almost 2 years ago
-
Target version deleted (
<strike>
_0.12_</strike>
)
Comment 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.
Comment 27
Updated by Jim Nelson 11 months ago
- Category set to library-mode
Comment 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.
Comment 29
Updated by Jim Nelson 8 months ago
- Target version changed from 0.15.0 to 0.16.0
Comment 30
Updated by Jim Nelson 6 months ago
-
Target version deleted (
<strike>
_0.16.0_</strike>
)
Comment 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