| Summary: | Improve key {unique} behavior for coupled files (jpg+raw) | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Michal Hlavinka <mhlavink> |
| Component: | AdvancedRename-file | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | caulier.gilles, marshallad, mrintala43, uwe.krause |
| Priority: | NOR | ||
| Version: | 5.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/commit/81ea8fd606ff8020e2806984d51fc5612fde4ab6 | Version Fixed In: | 7.6.0 |
| Sentry Crash Report: | |||
Michal, This file still valid using digiKam 2.4 ? Gilles Caulier I can't speak for Michal, but I have the same problem in 2.4.x still.
The main problem seems to be that {unique} only applies to the one option that precedes it. So [date]{unique}.[ext] create unique numbering if two photos with the same date exist, even if they have a different extension.
The minimal change to solve this would be to allow {unique} to apply to a group of options, for example ([ext][date]){unique}. Then unique numbering would only be used if date and filename extension are equal. The {range} modifier could be used to get rid of the initial [ext], if necessary.
Matti
(In reply to comment #1) > Michal, > > This file still valid using digiKam 2.4 ? > > Gilles Caulier Hi Gilles, it's still the same (tested with digikam 2.5.0). The only change is I'm allowed to start batch rename with collisions and handle them when collision is reached. It still thinks there are collisions even when there are none. abc.jpg and abc_1.cr2 despite abc.jpg and abc.cr2 can coexist quite fine. So bug/feature description is still valid except OK button is no longer disabled, when there are collisions. Michal Just tried 2.6 in Ubuntu 12.04.
{unique} still will not let .jpg and .cr2 share the same name.
Art
Art, This file still valid using last digiKam 4.2.0 ? Gilles Caulier Hi Gilles, it still is in 4.1.4. It seems this feature will never make it :-( Best Regards, Uwe Hi Gilles, it still is in 5.10. It seems this feature will never ever make it :-( Best Regards, Uwe Git commit 81ea8fd606ff8020e2806984d51fc5612fde4ab6 by Maik Qualmann. Committed on 06/02/2022 at 09:31. Pushed by mqualmann into branch 'master'. fix that the unique modifier respect the file extension FIXED-IN: 7.6.0 M +1 -1 NEWS M +5 -5 core/utilities/advancedrename/common/parser.cpp M +2 -2 core/utilities/advancedrename/common/parser.h M +1 -1 core/utilities/advancedrename/common/rule.cpp M +5 -3 core/utilities/advancedrename/parser/modifiers/uniquemodifier.cpp https://invent.kde.org/graphics/digikam/commit/81ea8fd606ff8020e2806984d51fc5612fde4ab6 |
Version: 1.6.0 (using KDE 4.5.90) OS: Linux I've tried to batch rename new files from camera. I always rename files to [date] so it's easy to process them when I put together pictures from more cameras. Files are *.jpg+*.cr2 , but sometimes I take more pictures within one second. But the result is "OK" button is disabled, despite name collisions are handled quite fine during renaming. When I use {unique} file.jpg and file.cr2 are always renamed to file.jpg, file_1.cr2 so I can't use it. When I do not use {unique}, I'm not allowed to rename files, nor change individual collisions, but I have to cancel renaming dialog, deselect files causing collisions, rename files and handle remaining files manually. a){unique} should add _<number> suffix only for complete name collisions (including file name extensions) b)add something new like {unique} with behviour from a) bonus: 1) start file name renaming even with collisions (inform with warning after clicking ok/warning displayed above ok button) and let them be handled individually 2)let user change file name collisions in old and new file names list. Reproducible: Always