PL7.1.0 (Win) Issues when changing a drive

This post is long and full of snapshots, the actual procedure is fairly simple but only necessary if you need to preserve ‘Project’ on Windows or ‘Project’ and ‘Advanced History’ on a Mac because these items only exist in the DxPL database.

Users need to be able to replace a drive for a number of reasons e.g.

  1. More space
  2. More speed
  3. Unreliable existing drive, i.e. failing drive
  4. Failed drive

Users typically copy the images or use a backup copy, change the name to the name of the drive being replaced and set the drive letter to the original drive letter and discover the new drive in DxPL.

All will appear to be O.K. if there are no ‘Projects’ in DxPL(Win) and no ‘Projects’ in DxPL(Mac) but with DxPL(Mac) the apparent loss of ‘Advanced History’ on the Mac and ‘Projects’ on both systems, if they existed, will not go unnoticed!

The reason for the problem is that DxPL does not use the ‘Label’ or the ‘Drive letter’ to recognise a disk drive it uses the ‘Volume GUID’ (other terms appear to be used for this unique identifier).

Do I need to do anything special:-

If the user is not using ‘Projects’ on DxPL(Win) or ‘Projects’ and/or ‘Advanced History’ on the Mac then providing all the edits have been written to the DOPs and metadata written back to the image, if required, then

  1. Take a backup of the current database, if possible (i.e. the drive still exists/works)

  2. Start with an empty database (or no database at all) and recreate whatever is required by discovering directories and thereby importing the images into a brand new DxPL database.

What happens if I just present the replacement drive to an existing DxPL database:-

If the ‘Volume GUID’ of a drive is not recognised by DxPL then it will continue to work as normal but each directory accessed by the user will result in new data being added to the database, the old data will remain intact but unused and inaccessible!

I believe (guess) that the ‘Volume GUID’ is used so that users can remove external USB drives from the system but it allows DxPL to recognise them if/when they return!

However, if the user intends to use a replacement disk, e.g. me replacing my F:\ drive with one of my backup USB3 drives, they will be “unlucky” unless they adopt the following procedure!

The database table that controls this access is the ‘Folders’ table in DxPL(Win) (a different naming convention is used for the Mac and the databases are not interchangeable).

‘Folders’ looks like this for a small test database

and the UUid (UniqueId) must tally with the ‘Volume GUID’ shown here

If a drive is accessed that does not match a UUid in ‘Folders’ then that drive will be considered as new and any database data relating to the old drive will be ignored and data will be taken from the “new” drive… i.e. the image, the DOP (if it exists) and from an xmp sidecar (if it exists).

Any ‘Projects’ will then get a “?” when attempting to access the image to which they “point” which cannot be found.

Other software will often detect such a potential mismatch and offer to take the “new” drive as if it is the “old” drive and continue without additional problem but no such facility exists in DxPL.

The “safest” way, I believe, is to patch the database to reference the GUID of the replacement drive, i.e. patch so that the new drive replaces the old drive in the ‘Folders’ Table in the PhotoLab.db database.

The software used for this is


and is available for Windows and MAC.

Before starting I must make a warning that this procedure is not endorsed by DxO and cannot be undertaken easily if the database to be patched has already “discovered” the new replacement drive, i.e. do not browse the replacement drive with DxPL if possible so that it remains unknown to the DxPL database!

If the new drive is already in the database it becomes harder to assign the UUid of that drive to another drive because of the rules governing the keys used in the database, i.e. the UUid must be unique in the database as it is on the system.

Step 1 - Back up the database:-

Use DxPL to make at least three backups. Unfortunately the utility used to patch the database does not allow the changed database to be given a new name when it is being saved.

So using DxPL make three backups using


i.e. to create

Step 2 - Obtain the GUID of the replacement/new drive:-

In my case I want to change from the H: drive to the F: drive , i.e. to reverse what I did in a previous test.

So I am going to change the UUid value in the database from “53cf648a-0000-0000-008a-000000000000” (the GUID for H:) to “f8435d17-32d6-11ed-94d4-448a5ba05907” (the GUID for F:).

This might help to use PowerShell to get the GUIDs for the operation. If the drive to be replaced is no longer available then that is not a major problem but the replacement GUID must be located and copied.

The PowerShell command is

GWMI -namespace root\cimv2 -class win32_volume | FL -property DriveLetter, DeviceID

So in my case both drives are available and I get

The GUID for F:\ is “f8435d17-32d6-11ed-94d4-448a5ba05907”
and for H:\ is “53cf648a-0000-0000-008a-000000000000” and the current value in the ‘Folders’ structure of “Backup_2023_12_07_01.db” is

Because the patch is going to be made to the 01 backup copy, DxPL can be open at this point.

Step 3 - copy the new GUID to the ‘UniqueId’ for the H: drive in the ‘Folders’ Table

and ‘Apply’ to get

This now needs to be written back to the database and sadly there is no way of changing the name of the database at that point.

so after ‘Write changes’

will contain the patched ‘Folders’ structure which in my case will mean that ‘Projects’ that were set up on the H:\ drive will now continue to work correctly on the F: drive, but only after that database is ‘Restored’ into DxPL.



which requires a ‘Restart’ and


But F:\ and H:\ were not exact copies so I acquired an Unwanted Virtual Copy and that risk will always be a potential hazard with recovering

1 Like

If this post doesn’t convince DXO that tying the database to a drive serial number is a bad idea, I don’t know what will.

Good on you for writing it up. Good luck to anyone dealing with this.


It is way harder to write up than it is to execute, it takes minutes to do but I am always concerned that if I write something with the assumption that a reader will not be encountering something they have never done before and written in a different language to what they are used to then they might get stuck part way through.

So the easy version

  1. Get a copy of DB Browser for SQLite.
  2. Create database backups (as many as you feel you might need, plus 1) using either the ‘File’'DxO PhotoLab database'Create a backup’ option of PhotoLab or by making copies of the database directly by using appropriate file management software.
  3. Use PowerShell to find the new drive and copy/note the GUID
  4. Open one of the backup copies of the database with “DB Browser for SQLite” and use ‘Browse Data’ to locate the ‘Folders’ structure
  5. Scroll until the drive to be replaced is shown on screen.
  6. Select the UniqueId field and replace with the GUID of the replacement drive and ‘Apply’
  7. Save the database using ‘Write Changes’, no option to ‘Write as’ is available so the copy of the database backup will be overwritten
  8. Use the ‘Restore’ option in PhotoLab to restore the amended database
  9. Hope the two copies were as close to one another as possible, depends on the frequency of taking and maintaining backups

It took longer to write the summary than it does to execute the procedure!

The database is not tied to the Drive serial number, the Drive serial number is used to look up the disk entry regardless of what label or drive letter it might have today after its journey to… wherever.

But some time after replacing my Hard drive I decided to re-investigate DigiKam and the first thing it did was to warn me about the Drive Serial Number (GUID) and ask if I wanted to update it.

Such a feature would be useful in DxPL or even a simple utility that allowed a replacement drive to be registered would be useful.

In the meantime if a user is desperate to preserve the database then a procedure exists and I have used it a number of times, mostly with USB3 SATA drives but in the example above with two hard drives.