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

[Ty Mayn]

thanks for clarifying that there is no rights management. And regarding the
database I am examining its behavior during repointing.
   One focus as a new user is understanding how images may be found again
by the database when those images are rearranged into new folder patterns.
   My testing is with about 15 image files in about 5 or 6 folders, some as
subfolders. Each time of hiding the folder collection by a rename of path
its clear that the database delivers its digikam metadata by display with
the thumbnails even if the real file path of the image files has been
obscured
    I have taken the small test database (15 files) and upgraded to
Digikam6 and loaded a much larger collection of a few hundred files in
about 10 folders.....knowing that the originals of those 15 files are
waiting there to be found on the first  intake of the larger collection.
   Sure enough the programming is designed to cycle through a matchmaking
of the existing files as they are discovered  in the new larger collection.
All prior tags for those 15 test files are preserved and displayed.   I
wonder if the program even skips the brief effort to generate a new
thumbnail for those known preexisting records that point to a thumbnail.
Presumably this is all based on discoveriing  a suitable identical
fingerprint for the file based on name, dates,filesize and a hash value and
loading transferring the metadata to the new record identifier (for all I
know the same database record number may be retained).
     I am not a programmer and I dont know what to call this preservation
instinct that is built into digikam.  Some programmer could have just as
easily designed to throw away all records and metadata when unloading a
collection or when loading a new collection that is missing some of the
formerly mapped image files.
    I have seen preservation behavior even where an old collection is
hidden by renaming, then unloaded, then replaced by loading a different
collection with absent files, then pointing to a new pattern of folders and
files that returns the missing files for inclusion ( rearranged folders).
     My reason for describing this is to learn what experienced users call
this and to know how dependable the behavior is.    I dont see this
behavior outlined in the digikam user manual which is excellent but finite
in scope (an undated work in progress AFAIK)
    If I were naming this "feature"   I would call it a database with
"unused record retention" and look upon it as an asset rather than
liability.  It deserves a warning in regards to what command actually
purges unused records (presumably by the maintenance tool) It also deserves
comment to know if there is any non manual trigger that kills surviving
records that are not in use in a currently loaded collection.
       I would cite the collection loading tools as  having  "record
repurposing by fingerprint"  for  "new collections with
intersection/overlap  of former record identities" . . It is clear to me
that a prior database pointed at a new image collection can have some
inheritance of metadata based on a matchmaking design.    This could
benefit from explanation of the behavior by programmers who know the
design.  A big question in this is whether the main database is purged
automatically (non manually) when certain events occur .... such as
reloading the thumbnail database.
    Users dont make any parts of the plane, each   just tries to understand
the ways it can be piloted.
Ty


On Thu, Feb 21, 2019 at 6:27 AM Maik Qualmann <metzpinguin at gmail.com> wrote:

> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20190222/709f927c/attachment.html>