Bug 498798

Summary: Onedrive re-downloading image files (jpg) after metadata changed using digiKam -- suggestion.
Product: [Applications] digikam Reporter: Jonkeren <josjonkeren>
Component: Metadata-ExifToolAssignee: Digikam Developers <digikam-bugs-null>
Status: REPORTED ---    
Severity: normal CC: caulier.gilles, metzpinguin
Priority: NOR    
Version First Reported In: 8.6.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Jonkeren 2025-01-17 13:43:46 UTC 
When using Digikam on Windows (just tried the weekly latest snapshot as well), with the images directory stored on OneDrive (the onedrive folder), when doing a metadata write-back to the file, the file is OK. It is then uploaded to OneDrive. OK. 

*BUT*
Then after about 1 minute, OneDrive re-downloads the file from the cloud -- thus overwriting the changes made, and restoring the metadata. OR: OneDrive downloads the file again, but this time with "-ComputerName" added to the file name.

I have seen many reports about this on the web, so I am not the only one.
Example: (exactly the same issue): https://www.reddit.com/r/onedrive/comments/1hteo4w/onedrive_duplicates_files_with_computer_name/

It has already been reported before - here for example: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg806084.html

I understand this "nothing to do with digikam" -- Or even ExifTool.... or the Perl Exiftool wrapper.
But I may suggest some addition to Digikam to try and circumvent this?

I have tried to solve this, by using many different settings for the metadata writeback (settings in digikam advanced options".
No matter what I do, I keep getting the same result.

*I SUSPECT* that it is some issue with the Windows file system in coordination with the OneDrive client.
I suspect that Onedrive detects a changed file (hash), but the file time stamp is not (correctly?) set or updated -- so it thinks the online file is newer, and downloads that again.

*SUGGESTION*
1. After each file write-back using the Exiftool backend, use a Windows "touch" equivalent ... like: copy /b filename.ext +,,
  See the answer here: https://superuser.com/questions/10426/windows-equivalent-of-the-linux-command-touch
  --> This way, the Windows file system and OneDrive (hopefully) see the 'hard pushed' (by Windows itself) change date/time, and syncs correctly to OneDrive, and keeps the correct file.
2. Check and possible change the Exiftool file write-back option: Does Digikam use "-overwrite_original" or the "-overwrite_original_in_place" option to write the files back? If so -- do I have the option to change those options? 

Another question / suggestioon And can I see some Exiftool LOG of the commands that Digikam sends to Exiftool, so that I can troubleshoot better?

Thank you very much.
Comment 1 Maik Qualmann 2025-01-17 21:39:53 UTC 
As the online documentation said "digiKam DOES NOT support virtual placeholder folders"

https://docs.digikam.org/en/setup_application/collections_settings.html#the-network-shares-specificity

This has nothing to do with ExifTool, it also occurs when writing with Exiv2.

Maik
Comment 2 Jonkeren 2025-01-17 22:12:17 UTC 
Hi Maik. Thanks. Yeah but but but.... :)
The Onedrive folder is not a " virtual placeholder folder" -- the file is saved just like anywhere else; same file system. The OneDrive exe just scans for changes / gets file change updates from the OS, and uploads the file(s). That's it.

So my suggestion was to "kick" the jpg file again from the OS after a change by Digikam, so that it is correctly registered as a change with the current date and time. I have a feeling that that's the cause.

Could you please answer my other question still please; the way I understand it now is that Digikam does not use all parameters of Exiftool, but first "builds" a command using Exiv2, and then pushes it off to Exiftool? Yes?
Then still, it might be a small thing to check which Exiftool parameters you used to do the writing. ("-overwrite_original" or "-overwrite_original_in_place"; or none) 

Also; can I see the output log of Exiftool somewhere? 
Thanks
Comment 3 caulier.gilles 2025-01-18 03:29:05 UTC 
Hi,

The debug traces are printed ont he console under Linux to show advanced information about digiKam processing. This include the ExifTool command line parameters.

Under Windows, this such console rules do not exists. You need to use the DebugView program from Microsoft for that, as explained here :

https://www.digikam.org/contribute/#windows-host

The ExifTool debug traces will look like this:

digikam.metaengine: Check ExifTool availability: true
digikam.metaengine: ExifTool "Load Chunks" "-TagsFromFile /mnt/data/Images/RAW/IMG_0057.CR3 -all:all -icc_profile -o -.exv"
digikam.metaengine: ExifToolProcess::readOutput(): ExifTool command completed
digikam.metaengine: ExifTool complete command for action "Load Chunks" with elasped time (ms): 223
digikam.metaengine: EXV chunk size: 3807
digikam.metaengine: ExifTool parsed command for action "Load Chunks" 1 properties decoded
digikam.metaengine: ExifTool complete "Load Chunks" for "/mnt/data/Images/RAW/IMG_0057.CR3"
digikam.metaengine: Metadata chunk loaded with ExifTool
digikam.metaengine: Loading metadata with "ExifTool" backend from "/mnt/data/Images/RAW/IMG_0057.CR3"
digikam.metaengine: Exif color-space tag is sRGB. Using default sRGB ICC profile.

Here ExifTool is used to extract the color profile from a CR3 RAW file before to preview image. The command line arguments are:

"-TagsFromFile /mnt/data/Images/RAW/IMG_0057.CR3 -all:all -icc_profile -o -.exv"

Best

Gilles Caulier