SUMMARY When a file is in a folder and the user tries to paste another file of the same name, dolphin has an option to suggest a new name, this works, but only if the file does not have a number in brackets. video: https://upload.disroot.org/r/frjf5fkp#fp38uiGnTrD9eot5eVUFSZN6ukbgFWxg7WeQpbCJfXQ= STEPS TO REPRODUCE 1. Create a file with any name and in brackets put some number, the year for example. something (2020).txt 2. Copy and paste this file into the same place and click to suggest a new name in the window that the dolphin will show OBSERVED RESULT The new name suggested will not be 'something (2020) (2).txt' but 'something (2021).txt'. EXPECTED RESULT The correct thing is not to change what is in parentheses (since this can be a useful identification for the file, the year in that case), but to add the '(2)' to the end of the file. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.2 Kernel Version: 5.6.10-arch1-1 OS Type: 64-bit
I have been able to reproduce this bug with the steps provided. Operating System: Arch Linux KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.2 Kernel Version: 5.4.38-1-lts
Thanks for reporting & confirming this bug. I can also reproduce this behavior, but while it is counterintuitive, I am asking myself how we can detect whether this is a deliberate naming action (such as "report (2020).txt") versus just previously copied files (e.g. if you copy "report.txt", it becomes "report (1).txt", then "report (2).txt" and so on).
I don't know if this can help, but when a file has more than a couple of parentheses, the only one that's renamed is the last one. (2020)hello(2020)world --> (2020)hello(2026) (2020)hello(2020)world(2020) --> (2020)hello(2020)world(2026)
Can confirm this is still an issue on git master. Created Test(2022).txt The suggested rename was Test(2023).txt