microsoft
[PowerRename] Use file modification date when renaming with `$YY-$MM-$DD` patterns
Summary of the Pull Request
This changes the behavior when renaming with date/time values to use the "Date Modified" file attribute as it is often more relevant than the currently used "Date Created" value.
PR Checklist
- [X] Closes: #36040
- [x] Communication: Commented in the contributing requests thread
- [ ] Tests: Added/updated and all pass
- [X] Localization: All end user facing strings can be localized
- [ ] Dev docs: Added/updated
- [ ] New binaries: Added on the required places
- [ ] JSON for signing for new binaries
- [ ] WXS for installer for new binaries and localization folder
- [ ] YML for CI pipeline for new test projects
- [ ] YML for signed pipeline
- [ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx
Detailed Description of the Pull Request / Additional comments
Also updates the UI string to reflect the file time type change.
Currently PowerRename can rename a file with $YY-$MM-$DD $etc formatted timestamp data, based on the file's "Date Created" time. However, the "Date Modified" field is often much more useful.
A common use-case for bulk renaming files and an example of "Date Created"s failings is standardizing filenames when copying files from a camera's SD card. Since the files are all freshly copied their "Date Created" field is set to the time of the transfer instead of the desired time of when the photo was taken, which is usually preserved in the "Date Modified" field.
Ideally the time metadata source used could be controlled with a settings option (See #6151).
Ideally (for the camera SD card backup case) image EXIF data could also be used in renaming (See #3880, I think this issue was potentially closed in error due to a misunderstanding). Currently exiftool seems to be the most feature-complete tool that works with EXIF data.
Validation Steps Performed
This change is currently untested. I've tried to compile yet have not been successful for reasons unrelated to the contents of this PR (aka ran out of harddrive space trying to get Visual Studio set up to compile in a VM)
Well I think the best way of implementing is an drop down in the rename ui to switch between the dates. Later exif can be added.
@htcfreek I absolutely agree, unfortunately I'm not adept enough at ~C#~ (edit: C++, don't know what I was thinking) to make that change.
The issue for making such a dropdown (#6151) is 4+ years old and has several complaints about the lack of progress, while the issue for using EXIF data is even older than that. I figured that this minor tweak addresses the main pain point (renaming copied photos) and would be a good stopgap measure until someone with more experience in C# can come up with a more complete fix.
If you or anyone else would like to take the reins on this PR or the underlying issue I'd be quite appreciative (no expectations though!), the issue has been bugging me for quite some time and it'd be lovely to have a full fix instead of this partial one. :)
@mwsundberg
C#? I see powerrename is a cpp project...
Actually, I have a hackathon demo before to use exif date in PowerRename. But I'm not familar with c++ especially in c++ GUI project.
And, I think we can't change the default behaviour. I agree the story you said in the description. I also think 'Date Modified ' is better than 'Date Created'. But this is a breaking change we need to avoid.
At least, we need to add a configuration to control this behaviour.
Ar... Copy with Created date reset is a common pain. While, using robocopy or xcopy can preserve for the attribute in case, e.g. robocopy "X:\source" "C:\destination" /E /COPYALL /DCOPY:T or xcopy "X:\source" "C:\destination" /E /H /K /O /X
I also think 'Date Modified ' is better than 'Date Created'. But this is a breaking change we need to avoid.
@moooyo, Thanks for reviewing the PR, even if it's somewhat unfortunately deemed a breaking change. I was hoping changing the UI string to reflect the behavior tweak would be enough for a low effort fix like this, but I guess it's not to be 😞.
@yeelam-gordon, Yeah, it is more than slightly annoying... thanks for the tips with those tools though!
Would you mind me to take over this PR? I think it's a good idea, but we still need a UI to control it. I have completed the UI part.
If yes, could you please grant the permission to me to for your repo? I want to merge my changed into your branch, so we can keep in a single PR to do it. @mwsundberg
Sorry to get to this late @moooyo, and thank you for picking up the patch and doing it proper, I really appreciate it.
Your PR looks good to my eyes, unless it's needed for posterity's sake I'm inclined to drop and close this PR, just keeping yours. I did add you as a collaborator on my fork's repo in case you do still want to use this PR, though I see no real reason to.
Thanks again!
Closing this PR since the feature was implemented with a proper UI control in PR#39653.