Bug 459483

Summary: Update documentation to explain how Digikam links metadata to images
Product: [Applications] digikam Reporter: richard.j.e.cooke
Component: DocumentationAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: caulier.gilles, metzpinguin, richard.j.e.cooke
Priority: NOR    
Version First Reported In: 7.8.0   
Target Milestone: ---   
Platform: Other   
OS: All   
Latest Commit: https://invent.kde.org/documentation/digikam-doc/commit/37c787043db83e60891ae07cab785291839ffd26 Version Fixed/Implemented In: 8.0.0
Sentry Crash Report:

Description richard.j.e.cooke 2022-09-21 09:41:44 UTC 
I can't find any information in the handbook or website about how Digikam links metadata to files.

Does it uses hashes? In other words, if I move my files or rename them, will Digikam remember all albums and tags associated with the image? (The same way KPhotoAlbum and ReadEra do).

Or does it associate metadata with an absolute disk path, and if that changes, the file is a total stranger.

Please update your documentation to explain this. I don't want to annotate all my files and put them in albums only to find I lose all my work when renaming and moving my folders.
Comment 1 richard.j.e.cooke 2022-09-21 09:42:43 UTC 
By hashes, I mean an MD5 or SHA checksum of the file
Comment 2 richard.j.e.cooke 2022-09-21 10:48:29 UTC 
No, this is not a wishlist issue. I'm not saying I want Digikam to use hashes.

I'm saying this is a documentation bug - how Digikam tracks files is not explained in the documentation when it should be.
Comment 3 Maik Qualmann 2022-09-21 11:43:08 UTC 
We have some things in the documentation that are missing or out of date. The documentation should be written by someone who speaks and writes native English. Unfortunately, writing documentation also seems to be very boring and there are few interested people.
But that's not what it is all about here. digiKam uses a hash, this is not a full hash of the file for performance reasons, but should still be reliable enough. The file size is therefore included. digiKam uses these parameters to try to find files again during a scan if they have been moved or renamed externally. This should also work well in current digiKam versions. You should test your use case with a small collection of images.
However, we recommend doing file operations within digiKam.

Maik
Comment 4 caulier.gilles 2022-12-24 10:14:07 UTC 
Git commit 37c787043db83e60891ae07cab785291839ffd26 by Gilles Caulier.
Committed on 24/12/2022 at 10:10.
Pushed by cgilles into branch 'sphinx'.

Next generation of digiKam documentation based on Sphinx/RestructuredText:
Add more technical details about Scan For New Item process and the relation between items and database registery using partial file hash.
Online handbook: https://docs.digikam.org/en/maintenance_tools/maintenance_scanitems.html
FIXED-IN: 8.0.0

M  +4    -0    index.rst
M  +1    -0    maintenance_tools.rst
A  +40   -0    maintenance_tools/maintenance_newitems.rst

https://invent.kde.org/documentation/digikam-doc/commit/37c787043db83e60891ae07cab785291839ffd26
Comment 5 caulier.gilles 2022-12-24 10:21:42 UTC 
Wrong url. Right one is : https://docs.digikam.org/en/maintenance_tools/maintenance_newitems.html