<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Some of my newbie reaction to digikam is in</div><div dir="ltr"><a href="https://mail.kde.org/pipermail/digikam-users/2019-February/028282.html">https://mail.kde.org/pipermail/digikam-users/2019-February/028282.html</a></div><div> And I would still welcome elaboration on questions posed there</div><div>   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.</div><div>      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.</div><div>     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. <br></div><div>    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).</div><div>    Is my observation correct? ( I like this behavior)</div><div>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?</div><div>   I have only tiny test observations which need confirmation or caution from experienced users.<br></div><div>   Here are my partial observations to old questions in my earlier post<br></div><div></div><div></div><div> Can digikam seek out matching files in any folder pathes even with files<br>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?)<br>  Is digikam programmed to find and matchup a partial collection of<br>filenames wherever and whenever encountered? Yes that's loading a new collection.<br>   If there is such match making to marry data rows to files, then does<br>that occur only once at the time of parsing out a newly assigned folder<br>collection, or ongoing at every wakeup of  the program? <br></div><div>    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.</div><div>   Thanks to anyone for more detailed answers to the new or old questions posed.<br></div><div>Ty<br></div><div>      <br></div><div><br></div><br><div><br></div></div></div></div>