[digiKam-users] database pointed at subset of same files in rearranged folders

[Maik Qualmann]

I have read your text only in part to understand what it is about. The answer 
is no. Whatever you are trying to rename the root folder etc, it will not 
work.

1. Digikam is currently not multi OS capable with the same database and 
different mount paths. But there is already an untested patch.
2. DigiKam has no rights management. Any user can delete or add tags. 
Likewise, it is not possible to hide folders from specific users.

Maik

Am Mittwoch, 20. Februar 2019, 08:30:47 CET schrieb Ty Mayn:
> Some of my newbie reaction to digikam is in
> https://mail.kde.org/pipermail/digikam-users/2019-February/028282.html
>  And I would still welcome elaboration on questions posed there
>    It is necessary that I use windows and currently 5.9digikam  It took me
> awhile to find the lonely digikamrc in  user/appdata/local.  I am testing
> without scan for files at startup  and moving the same test files to
> different devices but in varied folder arrangements.
>       if I rename the root filesystem folder of a collection root to hide
> it from the stored  named configuration collection, I discover that digikam
> kindly delivers the stored collection of thumbnails complete  with non
> embedded digikam tags and captions, but of course no larger preview
> images,  Thats nice  and it tells me that the core datarecords work hand in
> hand with the thumbnail database up to the point of calling a full image.
>      If I repoint the configured collection to the same image files with a
> few deleted  (as well as rearranged in folders)  the program efficiently
> shows only those files discovered.  When i cycle back to point to the full
> collection (rearranged yet again and under a newly named root on a new
> device)  then I am pleasantly surprised to find that  coredatabase has
> retained the tags and captions of the replaced missing files discovered in
> the repointed  collection,  I notice no disc activity to suggest that
> thumbnails were rebuilt for those recovered images.
>     This tells me that the coredatabase saves records of metadata for
> images parsed in previous collection trees that have been removed. The
> records are immediately available when the same images (or fingerprint) are
> encountered in a rearranged collection .The thumbnails database appears to
> be saving those thumbnails also (unless I missed witnessing the brief lag
> to rebuild in my test of a few restored images).
>     Is my observation correct? ( I like this behavior)
> New question:   If I tag a larger collection (1500+) and trouble the
> processor to create thumbnails, can I do large rearrangements of folders
> and subfolders at a later time with a regular filemanager ....and... have
> some reasonable expectation that digikam will find  and matchup its
> corresponding records for moved rearranged files in a new collection?
>    I have only tiny test observations which need confirmation or caution
> from experienced users.
>    Here are my partial observations to old questions in my earlier post
>  Can digikam seek out matching files in any folder pathes even with files
> distributed across differing folder trees? Yes  existing records and
> fingerprints are reviewed when loading any new collection. ( Is a duplicate
> record is placed if the fingerprint matches but the path is new?)
>   Is digikam programmed to find and matchup a partial collection of
> filenames wherever and whenever encountered? Yes that's loading a new
> collection.
>    If there is such match making to marry data rows to files, then does
> that occur only once at the time of parsing out a newly assigned folder
> collection, or ongoing at every wakeup of  the program?
>     It appears that existing data rows in the core database are  matched to
> files discovered in an assigned collection only at the time of first
> configuring a collection..... unless there is configured scan at startup or
> a manual maintenance scan for new images.  A scan should discover new
> images that match prior and unloaded database records or entirely new
> images with no matching database record.
>    Thanks to anyone for more detailed answers to the new or old questions
> posed.
> Ty