Bug 420403

SUMMARY

While removing a large number of temporary tif files from several album directories I noticed that not all of the files were always deleted.

The process I was using to delete the files was to use a filter to display only tif files, selecting them all, hitting the Del key, and then selecting Move to Trash in the popup that was displayed. I did this in a number of folders and each time the pattern was very similar. It was rare that all files were deleted, often 2 or 3 remained and a "Could not move image xxx to collection trash" error was reported in a popup for each file that was not deleted. 

On repeating the delete on the files that were not deleted, sometimes they would then be deleted, but more often than not, one would be left that could not be deleted even with many attempts.

STEPS TO REPRODUCE
This problem does not always occur, but I have seen in on a number of occasions now, and was always doing this:

1. Turn on filtering by file type
2. Select all filtered files
2. Hit Del key
3. Select Move to Trash in popup
4. Some files are not moved to trash and digiKam reports a "Could not move image xxx to collection trash" error in a popup
5. Repeat Delete
6. Some more files may be deleted, the final file cannot often not be deleted.

OBSERVED RESULT

Sometimes not all of the files are deleted

EXPECTED RESULT

All files should always be deleted.


SOFTWARE/OS VERSIONS
digiKam Version: 7.0.0-beta2
Windows:  Windows 10
KDE Frameworks Version: 5.65
Qt Version: 5.14.0

ADDITIONAL INFORMATION

I spent some time looking into this, but there was noting that I could see that differentiated that file that could not be deleted from any others, there were not definitely not any permissions errors. 

I also noticed that I could not move the file to another directory/album in digiKam and I got the same error when I tried.

More interestingly during later investigation of a single incident, I also noticed that I could not delete the file from Windows Explorer either, as it said that "digiKam had the file open".

Even more interestingly, when I quit cleanly out of digiKam (view browse => quit) the file was still locked!!!  Then I noticed that digiKam was still running in the background and had not terminated cleanly (note that I only ever had one copy of digiKam visibly running at a time).

This issue was not limited to this one occasion, it happened a number of times on previous days as well. 

Once I cleaned up the rogue process, the file could be deleted without any issues, so potentially the digiKam process may have been been getting itself into an unexpected state during the delete operations?