I'm also experiencing this problem. This is a major issue, since the renaming process stalls once it encounters a conflict, thus batch renaming is broken if the batch has conflicts :(

This issue with non-atomic batch rename was fixed in 5.5 (or maybe earlier) - now Digikam checks for conflicts with existing files and doesn't allow to start batch rename if there are conflict.

Indeed Digikam now doesn't allow to start batch rename if there are conflicts, but that doesn't really fix the workflow problem :(

My current workaround (w/ v5.6.0) is:

- create a sub-directory 'tmp' and move all photos to be renamed into it
- select a limited number of photos
- try to rename
- in case of conflicts select the first N photos without conflicts and rename them
- move the renamed photos up into the actual album directory

- select a limited number of photos
- try to rename
- in case of conflicts select the first N photos without conflicts and rename them
- manually rename the first photo since it has a conflict
- move the renamed photos into the actual album directory

- repeat until all photos have been renamed

This is extremely cumbersome compared with the previous behavior. Please provide some kind of reasonable solution.

I find the current behavior very pleasant. But everyone has their own workflow. Which string to rename you use?

Maik

The major problem with the current operation is that if a file would rename the same as current, so retain its current name, then it fails.  
If I use rename on a bunch of RAW files, then some will stay with their current name, so they all fail.  Any workaround is a real pain.  
Please just provide an option to ignore all failures and rename all the ones that can be renamed.

I don't find the current behavior pleasant at all and the workaround is very time consuming. Perhaps the behavior should be configurable if others really appreciate the current one.

The string I use is:

[date:"yyyyMMdd_hhmmss"]_[cam]{replace:"Canon EOS 80D","EOS 80D",i}{replace:"FUJIFILM","Fuji",i}{replace:"Canon EOS REBEL SL1","EOS Rebel SL1",i}{replace:"OLYMPUS CORPORATION","Olympus",i}{replace:"Canon PowerShot G9","G9",i}{replace:"Canon EOS 60D","EOS 60D",i}{replace:"Canon PowerShot S100","S100",i}

Obviously the main problem are photos with the same timestamp.

*** Bug 391746 has been marked as a duplicate of this bug. ***

(In reply to Maik Qualmann from comment #7)
> *** Bug 391746 has been marked as a duplicate of this bug. ***

Hi,

Sorry, i wasn't sure it was the same bug. Thanks for your work :)

Git commit 296632cb79d67b6166840d406182bcd71623ca6d by Maik Qualmann.
Committed on 13/03/2018 at 21:45.
Pushed by mqualmann into branch 'development/6.0.0'.

first step to factoring the IOJob class with a IOJobData container
To perform database operations only after successful file operation
or to add a dialog for user intervention
Related: bug 381625, bug 377719

M  +125  -173  libs/database/utils/dio.cpp
M  +23   -31   libs/database/utils/dio.h
M  +1    -0    libs/iojobs/CMakeLists.txt
A  +219  -0    libs/iojobs/iojobdata.cpp     [License: GPL (v2+)]
A  +91   -0    libs/iojobs/iojobdata.h     [License: GPL (v2+)]
M  +12   -8    libs/iojobs/iojobsmanager.cpp
M  +10   -16   libs/iojobs/iojobsmanager.h
M  +22   -26   libs/iojobs/iojobsthread.cpp
M  +11   -22   libs/iojobs/iojobsthread.h

https://commits.kde.org/digikam/296632cb79d67b6166840d406182bcd71623ca6d

Git commit 2b26c502d2f1cd9ef9fe661271df530922e6096a by Maik Qualmann.
Committed on 15/03/2018 at 20:31.
Pushed by mqualmann into branch 'development/6.0.0'.

now we can skip the file if the renamed file name already exists
Related: bug 377719

M  +1    -1    libs/database/utils/dio.cpp
M  +0    -1    utilities/advancedrename/advancedrenamedialog.cpp
M  +7    -4    utilities/advancedrename/advancedrenameprocessdialog.cpp

https://commits.kde.org/digikam/2b26c502d2f1cd9ef9fe661271df530922e6096a

The current behavior of digiKam-6.0.0 is that after renaming, it is possible to rename the failed images again. I find this behavior better than a dialog during the rename process. I close the bug now, if necessary re-open the bug.

Maik