| Summary: | {unique} does not take file extension into account | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | grubz5 |
| Component: | AdvancedRename-Import | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version First Reported In: | 8.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed/Implemented In: | 8.6.0 | |
| Sentry Crash Report: | |||
| Attachments: | Demonstration of bug | ||
Created attachment 176029 [details]
Demonstration of bug
Nevermind... I found the "a" option for the unique modifier that reintroduces the expected behavior. I did read all the patch notes, but I either missed this change (very possible) or it wasn't mention :) "a" key for the advanced rename unique modifier is described in the online doc here : https://docs.digikam.org/en/main_window/image_view.html#renaming-photograph Best Gilles Caulier |
SUMMARY Given raw+jpeg photo pairs, when importing or batch renaming these photos, the file extension is not taken into account by the {unique} modifier, which causes one of the photos in each pair to have a "_1" after it instead of them both sharing the same name (different extension). STEPS TO REPRODUCE 1. Start an import or batch rename procedure on photos that are in raw+jpeg pairs 2. Use "[date]{unique}" as the renaming options 3. Observe incorrect names OBSERVED RESULT Each pair has one file with the expected date name, the other has date_1 as the name. EXPECTED RESULT Pairs should share the same name. The extension should be the only thing that differs. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION I believe this to be a regression, as I have been using this workflow for a long time and never had an issue until upgrading to 8.5.0. I believe it was working properly in 8.0.0.