Bug 465015

Summary: Moving a video with a colour tag to a directory containing a video with the same name removes tag during rename
Product: [Applications] digikam Reporter: tony
Component: Tags-ColorsAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: metzpinguin, tony
Priority: NOR    
Version First Reported In: 7.9.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: https://invent.kde.org/graphics/digikam/commit/d334a27bb1dd6dfc1fd13fca814d326caf3f9c48 Version Fixed/Implemented In: 8.0.0
Sentry Crash Report:

Description tony 2023-01-29 22:32:47 UTC 
SUMMARY
When moving a video with colour tags applied from a subdirectory to a directory with a video of the same name using the rename mode, the new renamed version of the video no longer has the colour tag applied after a refresh.

STEPS TO REPRODUCE
1. Enable both reading from and writing to xmp sidecar files.
2. Have a video in a directory (eg: foo/bar/video.mp4)
3. Have a video with the same name in another directory (eg: foo/video.mp4)
4. Apply a colour tag to the video in the original directory (eg: apply the 'green' tag to /foo/bar/video.mp4)
5. Move the video to the other directory (eg: drag and drop foo/bar/video.mp4 into foo/video.mp4)
6. Digikam will warn you there is already file with the same name and prompt you whether it should skip, overwrite or rename.
7. Select rename.
8. Now, in foo/, digikam will show video.mp4, and video_v1.mp4 (the renamed file), with video_v1.mp4 having the green colour tag outline when in thumbnail view
9. Refresh foo/ using F5 or another way.
10. The colour tag will be cleared from the file that was moved. (video_v1.mp4 will have no colour tag).

OBSERVED RESULT
The colour tag is removed from the video that was moved after it was renamed by Digikam after the directory is refreshed

EXPECTED RESULT
The colour tag should remain applied to the video file.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Linux 6.1.8-zen1-1-zen
(available in About System)
KDE Plasma Version: 5.26
KDE Frameworks Version: 5.102 
Qt Version: 5.15.8

ADDITIONAL INFORMATION

- I'm not sure if this is specific to videos, or is a more general issue with all items in a library. I haven't had the chance to check with images yet.
- I have reproduced this on both Digikam 7.9 as well as the beta for Digikam 8.0, it seems to happen all the time when following the steps below.
- I have XMP sidecar files enabled, and I have Digikam set to both read from and write to sidecar files. This may or may not be related, I haven't had the chance to check this without sidecar files enabled.
- I have seen this happen on colour labels, I have not tested if it also impacts other tags.

In short - this is the most specific configuration this issue applies to, but it may be more general. 
I will try to add a screenshot or video later today if needed
Comment 1 Maik Qualmann 2023-01-30 07:00:52 UTC 
The problem can occur if in the target album the video does not have a sidecar yet. Then the video file itself is renamed when you move it, but the sidecar keeps its name.

Maik
Comment 2 tony 2023-01-30 18:46:44 UTC 
(In reply to Maik Qualmann from comment #1)
> The problem can occur if in the target album the video does not have a
> sidecar yet. Then the video file itself is renamed when you move it, but the
> sidecar keeps its name.
> 
> Maik

Hi Maik, thanks for the quick reply. I just tried after creating sidecar files for the video in the target album by assigning it a different colour label (eg: blue), and it seems to keep its label while it is lost on the renamed video. I was under the impression that Digikam does the same copy/move/rename operations to sidecar files such that they follow/match the file they correspond to - is this not the case?
Comment 3 Maik Qualmann 2023-01-30 19:11:58 UTC 
I'm currently working on a bug fix.

Maik
Comment 4 Maik Qualmann 2023-01-30 20:54:55 UTC 
Git commit d334a27bb1dd6dfc1fd13fca814d326caf3f9c48 by Maik Qualmann.
Committed on 30/01/2023 at 20:53.
Pushed by mqualmann into branch 'master'.

fix sidecar handling when moving or copying files
FIXED-IN: 8.0.0

M  +2    -1    NEWS
M  +6    -3    core/libs/database/utils/ifaces/dio.cpp
M  +16   -0    core/libs/iojobs/iojob.cpp
M  +81   -0    core/libs/threadimageio/engine/dfileoperations.cpp
M  +8    -0    core/libs/threadimageio/engine/dfileoperations.h

https://invent.kde.org/graphics/digikam/commit/d334a27bb1dd6dfc1fd13fca814d326caf3f9c48
Comment 5 Maik Qualmann 2023-01-30 20:58:29 UTC 
Due to the size of the changes and existing changes to the IO file functionality, we will no backporting this change to digikam-7.10.0.

Maik