| Summary: | digiKam DB maintenance can not tell difference between two external drives (same type and size) | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Nathan <epostgateway> |
| Component: | Database-Media | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | brendan.selkirk, caulier.gilles, metzpinguin, shaun |
| Priority: | NOR | ||
| Version: | 5.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/-/commit/f48fc133ec0f0e5656d4d21fff52278e3d81a636 | Version Fixed In: | 8.2.0 |
| Sentry Crash Report: | |||
|
Description
Nathan
2018-09-19 09:32:29 UTC
I have not looked at it yet. If both hard drives return the same UUID (in Windows this is a volume serial number), digiKam can not do anything. I suspect that the disks were not reformatted and have the same factory image with the same volume serial number. Presumably the problem will be solved if the disks are formatted. Maik Confirmed using CMD 'vol G:' that both drives have the same Volume Serial numbers. Although different names. I also however checked the HD serial number using CMD 'wmic diskdrive get serialnumber'and confirmed these are different. It seems then that DigiKam should be basing its identification on the HD serial and NOT the Volume serial. This behaviour should probably be corrected in the software? If i'm not too wrong, this job is delegate to KF5::Solid API. Sound like the Windows code in this framework component is not enough. Gilles Caulier Q : Which digiKam version do you use and Which KF5 version is used in background. Look in Help/Components Info for details. Gilles Caulier Yes, KF5::Solid is used for that. But it is completely correct to use the volume serial number, it should/must be different. So you have to reformat one of both hard drives. Maik As a justification, imagine they have to clone the hard drive because it starts to fail. If the hard disk serial number were used, also a completely new reading of the new disk starts. With the volume serial number the new hard disk would be accepted immediately. Maik I am using Digikam 5.9.0 Buid date Mar 18 2018; The drives (WD Elements) were bought fresh and Bitlocked; no formatting at the time. Is it not the case that if the volume serial of external drives can be the same out of factory as these apparently were then this is not the best serial identifier to be pinning Digikam onto? Therefore it may well be a common matrix to use but I think we could do better by instead using the HD serial which apparently is more unique? I think most users would be both surprised at having separate HD's confused and messing with DigiKam database; and also surprised that a cloned HD be able to fool Digikam into thinking it was the original? In fact a 'migrate database volume reference' tool might well be also a good idea for moving over to a backup device. The volume serial number is used for identification: https://en.wikipedia.org/wiki/Volume_serial_number Another point is we do not have access to the hard disk serial number via the KF5::Solid API. Native extra code would be necessary. Maik Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just released ? https://www.digikam.org/news/2018-12-30-6.0.0-beta3_release_announcement/ Hi, Can you check if this problem still exist with last weekly bundle build of digiKam 7.0.0 available here: https://files.kde.org/digikam/ Thanks in advance Gilles Caulier digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier *** Bug 441019 has been marked as a duplicate of this bug. *** *** Bug 441539 has been marked as a duplicate of this bug. *** Hi Nathan and happy new year, What about this file using current 7.5.0 pre-release Windows installer available here : https://files.kde.org/digikam/ Thanks in advance Gilles Caulier @Nathan, digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier Git commit f48fc133ec0f0e5656d4d21fff52278e3d81a636 by Maik Qualmann. Committed on 09/09/2023 at 21:28. Pushed by mqualmann into branch 'master'. use a UUID file for the primary detection of the right collection - The UUID file is saved in the ".dtrash" folder as "digikam.uuid". - The "digikam.uuid" file can be deleted, the detection goes back to the previous mechanisms, it will be created again at startup. - This commit also fixes a problem when creating the DTrash folder/info directories. Related: bug 470556, bug 452299, bug 345391 FIXED-IN: 8.2.0 M +9 -1 NEWS M +1 -1 core/libs/database/collection/collectionmanager.cpp M +8 -8 core/libs/database/collection/collectionmanager_album.cpp M +117 -82 core/libs/database/collection/collectionmanager_location.cpp M +125 -3 core/libs/database/collection/collectionmanager_p.cpp M +7 -0 core/libs/database/collection/collectionmanager_p.h M +20 -9 core/libs/dtrash/dtrash.cpp https://invent.kde.org/graphics/digikam/-/commit/f48fc133ec0f0e5656d4d21fff52278e3d81a636 |