@bjnelson Not with DxPL(Win) and I suspect not on MacOS as well! The reason why DxPL is not “confused” by such an occurrence is because it relies on another field (the UUID) and it is that which then throws a spanner into the works with respect to the second part of your query
It is essentially impractical (impossible) to move large numbers of files via the DxPL user interface, thereby retaining the link between the database entries and the newly (re-)located files.
Worse the mechanism that avoids issues with the drive letter now means that it is “impossible” to present the old images on a new disk except as just that, new images, i.e. with the final state of the edit from the DOP but minus the ‘Advanced History’, which isn’t available to Windows users beyond the current session anyway!.
In addition, on both platforms all the project references will now point to “orphaned” database entries. Any other issues relating to the Mac platform I simply do not know about and sadly the procedure I am about to outline works on Windows but may or may not be made to work on MacOS?
So the “glue” that holds the database data to the original data is a structure called ‘Folders’ in the database and this is what it looks like in a test I ran yesterday
Drive T: is a USB3 connected SATA SSD and it contains a folder structure represented by ‘Id’ 6 pointing to ‘Id’ 5 etc. which finally points to ‘Id’ 4 which has a UUID of “270b17f5-0000-0000-0000-100000000000” and is designated as EFDOPVolume, i.e. it looks like this
I also set up a number of ‘Projects’ in DxPL pointing to the images from those directories.
I also had another USB drive connected to the machine that had an identical path structure but that was connected as J: and that drive will have its own unique Device (Volume) Identifier and using Powershell I was able to locate the Device Id for all drives on the system with only T: and J: being of interest for this test
So from your perspective T: represents your current USB drive and J: represents you new, faster, bigger etc. USB drive. You were fortunate to have your images on a USB drive because had they been on an internal drive then …
In my case T: represents my internal drive and J: represents my USB connected backup drive which is essentially a copy of my main drive. In the event of failure it would be good to be able to keep any ‘Projects’ I had created intact and that means I need to be able to “marry” the database complete with the ‘Project’ references to the images on the replacement drive.
Please note that if the database is lost then “simply” presenting the images with their DOPs will ensure that no editing data is lost but the DOP does not contain the ‘Advanced History’ (I believe) nor does it contain the ‘Project’ data!
So using DB Browser (SQLite) I need to replace the Device Identifier for the Device entry in ‘Folders’ with the Device Identifier for the “replacement” drive which must never have been introduced to the database!
- Backup the database, once or twice or … and close DxPL
- Start DB Browser
- Open ‘Folders’
- Copy new value for J: over the old UUID for ‘T:’ using the value from PowerShell in my case
- Paste that entry over the old value (for T:)
- Save changes and we have
- Close DB Browser and start DxPL
- Test for valid ‘Project’ references which all worked fine!
As shown the actual work is not really difficult but as for DxO doing anything about it …!?
Sorry this is the procedure for DxPL(Win).
Regards
Bryan