Bug 117561 - Should store hashes of files, cope if file is moved
Summary: Should store hashes of files, cope if file is moved
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Files (show other bugs)
Version: 0.8.0
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-03 06:20 UTC by Adam Porter
Modified: 2019-12-25 15:48 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Porter 2005-12-03 06:20:41 UTC
Version:           0.8.0 (using KDE KDE 3.4.3)
Installed from:    Debian testing/unstable Packages

I just did some cleaning up of my digikam root tree.  I switched from
Picasa to digikam, and the directory structure was less than ideal.  I
removed empty dirs, dirs with just Picasa.ini files, etc.  I moved
some dirs that were children of pointless dirs to the root level, etc.

So, when I restarted digikam, it noticed that the files weren't where
they used to be.  But instead of noticing that they had simply moved
to a new location, it insisted on removing them from the database
entirely.

Frankly, that womps.  Now I have to retag all of those images.

digikam should store a hash of every photo in the database, and when
it rescans the tree, it should notice if a file has moved or been
renamed, and it should be able to cope with that by using the hash as
the file's identity, not its filename or location in the directory
tree.

Please don't take this the wrong way; I really like digikam, and I
want to help make it the best photo management app for Linux.
Comment 1 Gilles Schintgen 2005-12-03 12:57:17 UTC
dupe of bug 110066
Comment 2 Tom Albers 2005-12-03 13:52:21 UTC
Thanks for that info Gilles.

*** This bug has been marked as a duplicate of 110066 ***
Comment 3 caulier.gilles 2019-12-25 15:48:44 UTC
Not reproducible using digiKam 7.0.0 beta1.