[digiKam-users] thumbdrive insertion creates phoenix album from ashes

[Ty Mayn]

 I believe I accurately witnessed an automated addition of an album
collection triggered by plugging in a thumbdrive which has a collection of
image folders.
    This is in ver6.0 and I am working to correct this before upgrade to 7.5
        I have previously posted that I had removed a type2 removable
collection that was accidental because it was an identical backup set of
image folders living on a thumbdrive. I had posted on how I noticed
that,after deletion, the accidental collection disappeared from the album
folder tree but the database files did not shrink by the expected 50% for
digikam4 and thumbnails. On the list I was informed that that excess could
either be vacuumed out or the database space would eventually be reassigned
to new images during later "additions" of images or entire albums

        so here is the next accident:  That thumbdrive containing backups
is plugged in and out often for other retrievals of backups servicing other
programs.  I witnessed an event while plugging that drive in for other
purposes WHILE the digikam6 program was open but not actively used.
            The thumbdrive plugin triggered an immediate display of an
entire duplicate unwanted album collection.  Of course the unwanted type2
collection reappeared in the management tool
SEttings>Collections>CollectionsSettings.
        This automated REadditon of the type2 collection seems to be coming
from some code that is automated to look for plugin of removable media.
          Furthermore this automated addition is being pulled from that
 doubling of the database (which I had elected to leave alone rather than
to "vaccuum"away)
          and an examination of the digikam4 database reveals that there is
NO 2nd entry of an AlbumRoot Identifier and SpecificPath
             I doubt that a formal addition of a new collection manually by
the user would fail to add a new RootAlbum field entry
         Of additional concern: neither collection is able to deliver full
image previews. They both report: "TheStorage Location of this image is
currently not available"
         The local collection has its function thumbnails. The intrusive
unwanted duplicates mapped to the removable drive do not display thumbnail
images...
         after all ... the unwanted collection seems to be  recovered by
some kind of coded probing which is searching for fields without asking the
salient question:
        "Am I authorized to be "Collection" according to an existing
explicit AlbumRoot field"

        It is common for a thumbdrive to serve multiple programs and other
backup events. We all know events that we have caused by ourselves during
speedy shifting between open windows that represent powerful open
programs.  What I witnessed I believe was digikam simply being open, but
idling unused, and Reinstalling a deleted  album collection just because
the code probed the partition of a newly mounted device long enough to find
some path names buried in its data base (buried following a proper request
for deletion)
           Such data  should not have to be vacuumed out ...but dead data
should not be revived without formal interaction with a user. Plugging in a
thumbdrive should not be a trigger or  instruction to a program without a
bold inserted dialog with the user.
        Thanks for a powerful program with occasional surprises
        Ty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20220126/3d08ab2f/attachment.htm>