https://bugs.kde.org/show_bug.cgi?id=514723
Bug ID: 514723
Summary: File rename seems to be unable to detect existing
files with name it wishes to assign, and that
generates a conflict
Classification: Applications
Product: digikam
Version First 9.0.0
Reported In:
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: minor
Priority: NOR
Component: AdvancedRename-file
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
If I select some number of images in an Album, and hit F2 and setup some
renaming pattern, often the system will have difficulty excluding legacy files
that match the file naming strategy (it doesnt remove matching files from the
namespace- it is creating a list, and trying to sequentially rename every file
based in that list). This seems to trip under several conditions, but one seems
easy to reproduce
STEPS TO REPRODUCE
There are some bugs with the file management happening with the latest version
that make this problem difficult to replicate. Example, I can create a folder
called _Test, setup an F2 naming pattern, rename the files, and all seems
fine. I delete a file- say, the 3rd of 4 total files in the _Test folder, and
copy in a new file. I will see the old file #3 reappear, or other files
duplicate etc.
In concept though, deleting a file or files and then adding new files seems to
cause problems, especially if the sort order of the new file's name puts it
within the body of the new naming scheme which can happen if you have multiple
nested folders on the same branch as:
_Test
Cats
Dogs
Parrots
If you have a simple rename like Dir.. Dir. Filename #. If you delete a file
from Dogs, and you find that you have a misclassified file in Cats and move
that over, the sort order seems to make the engine want name that file as _Test
Dogs1.xxx even if that file already exists. So in running an F2 to cleanup a
merged set of files, I tend to have to append a fake suffix like 'bb' to the
pattern, rename the entire contents of the album, and then remove the suffux to
rename it back to what it should have been to begin with.
Once the file pointer/cache problems are fixed, Ill diagnose this better. But
in principle, the system should never try to rename a new file to that of an
existing file if that existing file's name follows the defined pattern. Since
that existing file will not be renamed unless there are blank files that
precede it, this will always lead to a naming conflict.
OBSERVED RESULT
EXPECTED RESULT
SOFTWARE/OS VERSIONS
Windows:
macOS:
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma:
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
