<div dir="ltr"> 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.<br>    This is in ver6.0 and I am working to correct this before upgrade to 7.5<br>        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<br>        <br>        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. <br>            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.<br>        This automated REadditon of the type2 collection seems to be coming from some code that is automated to look for plugin of removable media.<br>          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)<br>          and an examination of the digikam4 database reveals that there is NO 2nd entry of an AlbumRoot Identifier and SpecificPath<br>             I doubt that a formal addition of a new collection manually by the user would fail to add a new RootAlbum field entry<br>         Of additional concern: neither collection is able to deliver full image previews. They both report: "TheStorage Location of this image is currently not available"<br>         The local collection has its function thumbnails. The intrusive unwanted duplicates mapped to the removable drive do not display thumbnail images...<br>         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:<br>        "Am I authorized to be "Collection" according to an existing explicit AlbumRoot field"<br>        <br>        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)<br>           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.<br>        Thanks for a powerful program with occasional surprises<br>        Ty</div>