Version: 1.2.0 (using KDE 4.4.4) OS: Linux I replaced the internal harddisk of my ThinkPad T42 by a bigger one. Today I just wanted to import some photos. On start Digikam said it didn't find the media that stores my internal collection with some UUID anymore. Reproducible: Didn't try Steps to Reproduce: - Create a collection on a local filesystem - Quit Digikam - Copy it so somewhere else - Recreate the filesystem so that it has a different UUID - Copy the collection back - Start Digikam again Actual Results: Digikam said my local collection cannot be found since the storage medium with some UUID is not available anymore. First I thought this was my external collection thus I marked it as removable medium. But then Digikam asked me about my external collection - it didn't got that an eSATA disk is a removable medium which has to do with Solid, Hal, Linux Kernel - here I also said it was on a removable medium. Then I wanted to fix this quickly cause I was absolutely not in the mode to fiddle with software problems: I removed the internal collection and created a new one, but then Digikam scans in every single image again although they are in the database. The current behavior induces data loss due to user mistakes - like the one I did: Deleting and recreating the collection. I have a backup, but its still annoying. Especially as I have no idea on how to handle that situation *other* than to delete the collection and recreate it again since Digikam just didn't offer me any sensible option. Expected Results: Digikam does not try to be smarter than me. It should not do any UUID checking for a collection stored on my *internal* harddisk. If I put a new bigger internal harddisk into my ThinkPad T42 and make the collection available at the same path again, Digikam just should *just* use it and *not* bother me about it. It might be wise to do UUID checking it for external ones, but even then Digikam should offer a "I moved my collection somewhere else" and/or "I changed media or filesystem, please update UUID" option. I can file enhancement requests for these.
This problem have been already reproted in this room. Marcel manage it already... Gilles Caulier
Normally, if the harddisk is gone but a different one at the same path is now available, this one will be presented preselected as your choice. Migration could be done automatically, but we prefer to ask the user here. See bug #175923. Now to find out why it does not work for you, I'd need the output of solid-hardware list details and the AlbumsRoots table of your database, preferably prior to the changes.
Is that in 1.2.0 already? There seems to be no newer package available for Debian at the moment. I still have old digikam4.db on an external eSATA disk from prior to moving to the new internal disk. I can try with that one and the old digikamrc as well.
Created attachment 48623 [details] solid-hardware list details Well one more difference is: On the old hardisk /home was a partition, on the new it is a logical volume. I am using LVM for new installation since current kernels support write barrier through LVM as well.
> I am using LVM for new installation since current > kernels support write barrier through LVM as well. Here you go: Solid, or rather HAL, now fails to recognize your /home partition at all (look for StorageAccess in the solid output. Only /boot is recognized). See the last comment in 175923. You are not the first one with such problems.
I have a similar Problem now with Digikam 4.2 after changing the filesystem from NTFS to ext4 because I thought that would be a wise decision...; Unfortunately Digikam now didnt find any pictures. The first I thought the error was that the changed name of the disk is the cause. But reverting this doesnt help. Now I see all my collections in the configuration dialogue but I cant dit them and change the path or edit irt at least. Although it's the same path but I think the UUID has changed...and I assume thats the problem ? I also didn't have a clue where digikam stores the paths to the collections. Having that path editable would be wonderful. What can I do to save my 80.000 pictures and several thousand tagged pics ? :-o
-> comment 2
Mike, yes it's UUID registered in database. But, as i tested recently, when you change disk or re-format it, UUID will be changed, and digiKam will not found the collection and will ask to relocate databse registration with new place/UUID. As Marcel said, look comment #2 Gilles Caulier
Thanks Marcel and Gilles for your veeery quick response ;-) Wow... appreciate that ! The strange thing is I was asked 2 options and neither of them seems to be appropriate: it was one of my collections that could be 1.) moved to removable state or 2.) do nothing. Neither helped. So I was let alone with no collections that were displayed..; I found several similar incidents in the net and luckily I found the hint with the sqlitebrowser. I also saw the problem with HAL but I dont think anything is broken but instead Manjaro is a rolling Release and maybe it handles some things differently regarding disks : for example my disks are mounted in "/run/media/USERNAME/DISKNAME" thats different to Ubuntu.. ; But however: now its working. The good thing is that solving problems leads to more knowledge...at least sometimes ;-)