I am using Photolab and its predecessors since 2014 on a Mac and now want to change my external disk drive by an external SSD. I already produced a backup of the database and manually re-exported the dop files for all photos since many have been created by old PL versions and lacked keywords and GPS data.
I already changed the disk drive once before and named the new drive in the same way as the old one. I could recover all activity history in that way. [Correction: I just realized that I reexported all these files with activity history with PL4 after the hard drive change. Sorry for the confusion]
However this trick does not work anymore. When I connect the new disk (no other external disk is connected) and open a folder within PL7, I donāt get any virtual copy as other users reported, but the UUIDs in all sidecar files in this folder get changed. With this new UUID, the activity history cannot be recovered.
Does this mean that the UUID somehow depends on the disk drive identifier? If yes, then there seems to be no way to preserve the activity history when changing the disk drive? This is a pity since sometimes we might want to go back to previous versions of a photo.
@umx , as far as I understand your post, you want to transfer your photo archive to a new external ssd without getting virtual copies and without losing history? Right?
The following is my opinion and, as such, is not that of everybody.
As much as the idea of a persistent history might sound attractive, it also can be a veritable can of worms.
If you are working with DOP files, you are producing and maintaining a record of the image and its virtual copies at the time the DOP file gets written to disk.
However, the database provides a second record and, at various points in an imageās history, may need reconciling with DOP files. Whether that reconciling takes the DOP or the database as the source of truth depends on (undocumented) algorithms. This is likely to be governed by the priority applied in the preferences and the timing of reading from the DOP or the database. None of this is clear enough to rely on and could, in theory, be subject to change by DxO.
I personally donāt use persistent history because, even within the history of a session, going back to a point in time and changing a setting promptly destroys all changes that were made previously after that point.
Since PhotoLab doesnāt order edits in a predictable manner, it is usually far better to rely on creating virtual copies at those points in the life of an image where divergence might be foreseen. These can be renamed and it is the simplest of matters to ārevertā to such a copy without touching any subsequent edits in more recent virtual copies.
The Windows version does not maintain a persistent history and, although DxO gave in to demands for the Mac version, I donāt see a great clamour for it in recent times by Windows users.
For what itās worth, my advice would be to look at your images on the disk where you have a persistent history and āconvertā them to virtual copies.
The persistence only appeared in PL4 so the makes me wonder what you used to do before then?
@Joanna Thatās because any clamour simply goes unheard!
@umx I have a problem as a Win 10 user that the database you are using on the Mac is not the same as the one on Win 10! Or rather I believe that much of it is essentially the same but the naming convention for fields is different.
So I believe you are encountering an issue that others have encountered and I did quite a bit of work on in the past. It revolves around another UUID in the āFoldersā Table in the database so I have
F: is the drive where all my photos are stored and that UUID I have highlighted needs to match the Volume GUID regardless of the name/label you assign to the disk, i.e.
If there is no match the āoldā drive data will be left in the database and the new data added as just that NEW!
There is no simple way to resolve the issue except to hack the database (arguably safer than changing the Volume GUID) and @platypus may be able to help because he is a Mac user!
Without digging into DPLās database just yet, are you willing and able to edit a SQLite database @umx ? If not, we can rest the case of database editing and proceed to create a new database from the files on the new drive.
Have a look at one of the tables in the DBā¦just to wet your appetite for risk and adventure:
The unique IDs of the drives correspond to the file system uuids of e.g. the data volume of an APFS drive. Other folders are linked to their parents trough āZPARENTāā¦and thereās a lot of other stuff that might want to be set correctly, which might need some guessing due to available documentation being equal to none. Replacing a drive name or UUID might work, but Iāve not searched the DB for other relations that might break an edited database.
Current versions of DPL donāt provide any means to copy or move entire folder trees. This means that youāll have to either edit the database or start a new one, once your tree has been copied.
Well I found an activity history for images back to August 2017 and I changed the hard drive two years later. So I concluded that the activity history persisted the hard drive change, but I just realized that this conclusion was wrong: all those images with activity history have dop files created by PL4 or later (had to check this on a backup). So it seems that I retouched all photos from August 2017 on with PL4 and forgot about it. Sorry about the confusion.
I might be able to modify the DB, but I wonāt do it. The activity history is nice to have, but not worth to mess things up. I will keep a backup of the database of the old drive and set up a new one for the new drive. According to what I have seen, all keywords and GPS data are now stored in dop files, so the activity history seems to be the only thing that I am loosing when moving to the new drive?
@umx The decision is yours but patching the database is not particularly difficult and the risk is low providing you follow this rule
Dump the database
Dump the database again
Dump the database again
When you think you have enough copies, Dump the database again and change the name to āLast Dump of DB do not use until copies have been madeā
Then you can patch the field. I am going to publish a topic today for Win 10 users because it is currently the only way to introduce a replacement backup copy on another drive to the system, i.e. I have my images of F: but a copy of all photos are also on a USB3 drive K:.
If F: failed for any reason I might replace it with another drive from a backup system or press K: into operation but to preserve the DxPL database and any āProjectsā then I would need to patch the database because DxO have not provided a simple command or utility to accomplish that function!
As @Joanna wrote, itās not quite clear how DPL syncs metadata and I therefore recommend to switch automatic .dop and xmp actions off. If you trust your sidecars to be up-to-date, have DPL import/read metadata manually with the respectove command from the file menu.
Just ran a very small proof of concept with editing the database:
Cloned āMacintosh HDā to an external SSD (using Carbon Copy Cloner)
Opened the DPL database and set the parent of āUsersā to the external drive
Opened DPL and found
a) that the edits had moved to the folder on the ext. SSD
b) that the original source files were recognized as new files
Even though the poc worked as expected, Iād not expose my prod. photo archive to such a manipulation. I just checked the edits and nothing else. Even though DPL works non-destructively with RAW files, thereād be a lot more tests to run in order to make sure that nothing gets damaged in the process.
As long as DxO does not support any such change, Iāll stick to Lightroom and its fairly robust database maintenence features.
Yes, I agree. It is a half-baked solution. Either the sidecar files should be the source of truth and the database should adapt to them or there needs to built-in functionality to copy a folder to a new disk while preserving all info.
Basically, the database is the one thing that PhotoLab needs and uses, but it makes sense to export metadata to files - and in case of the .dop sidecars, everything is in them, except the history.
The .dop sidecars can be understood as distributed backupsā¦and a possibility to create a new database, should it get off-track, which happens easily. The database backup that can be created from the command in DPLās file menu can be used as backup which includes editing history - and all the inconsistencies that can develop over time. No free lunch
