Bug 435680

Summary:	Comparing files being downloaded with target location files
Product:	[Applications] digikam	Reporter:	Kokos <konrad.kostecki>
Component:	Import-History	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	wishlist	CC:	caulier.gilles, metzpinguin
Priority:	NOR
Version:	7.3.0
Target Milestone:	---
Platform:	Other
OS:	All
Latest Commit:		Version Fixed In:

Description Kokos 2021-04-13 07:05:00 UTC

This is a feature request. There is already a setting in camera/import behaviour section to skip/replace/create_copy files in case they already exist in target location. Can we do this more reliable to classify file as already existing basing not only on its filename but also other attributes like at least file size?

Please reassign if I selected wrong component. Thank you.

Comment 1 caulier.gilles 2021-04-13 07:36:50 UTC

Hi, There is already a download hstory fingerprint recorded in database to identify which files are already copied from camera to the collections.

But i'm not sure if code is always actif currently.

Gilles Caulier

Comment 2 Kokos 2021-04-13 07:50:03 UTC

(In reply to caulier.gilles from comment #1)
> There is already a download hstory fingerprint recorded in database to
> identify which files are already copied from camera to the collections.

Thanks, I know, but I can imagine situation that you reset digikam, clean home directory or reinstall operating system and with fresh digikam instance you perform import of SD card which contain files already downloaded. Fingerprint history is empty, but files are already in target location. By default digikam import just creates duplicates with a different name. In case, just before downloading, it recognizes that filename and sizes are identical it could suggest skipping those files if there would be an option for that. I think it would be handy. I'm not talking here it should be a default setting, definitely not, but in some cases it could be very helpful.

Comment 3 Maik Qualmann 2021-04-13 11:02:33 UTC


*** This bug has been marked as a duplicate of bug 319001 ***