@CHPhoto I have done quite a lot of work testing moving data around, including co-hosting the database on the same drive as the images but I believe that particular idea is only possible with Windows because I believe (and you can confirm) that you cannot move the database from its default location on a Mac?
But I have moved directories with DOPs successfully between two systems, with a database on each system, without getting “Unwanted Virtual Copies” and I have also moved directories between systems and got Virtual Copies!?
The later items in the “Unwanted Virtual copies” post from Unwanted virtual copies - #86 by BHAYT onwards identifies how the problem occurs, namely when DxPL identifies a clash between a database entry Uuid and a DOP Uuid.
This “suggests” to DxPL that they are not referring to the same edit so the database entry becomes the [M]aster copy (edit) and the DOP entry becomes the VC[1] entry and a new larger DOP containing the data for [M] and [1] is created!
I actually managed to take edited images (image + DOP) to another system and it was absorbed into that system with the same Uuid, and then carrying that back to the first system was perfectly O.K…
These tests were part of https://forum.dxo.com/t/unwanted-virtual-copies-and-moving-dxpl-edited-images-dops-between-system-revisited/2894.
A similar problem occurred in my “mistaken” test, the reason that it was a mistake was that I was deliberately going to test the scenario but actually did it by accident. When B is discovered by DxPL the database entries are created for all the images in the directory. If a new DOP is then copied into the directory it is always going to clash with an existing database entry!
There is no real “fix” for this situation, other than avoiding it altogether and I believe that on the Mac some elements of my suggested “recovery” strategy are not actually possible on a Mac because there is not an identical set (to the Win version) of directory options available!?
So you may have two situations to contend with
- the A to B situation on the laptop and
- then the switching from processing on the laptop to processing on the Mac mini desktop system
That represents a challenge or rather multiple challenges, made even more challenging because you are using two systems with different features available!?
This is the database structure that holds images called ‘Items’ and the snapshot is after I have discovered A (4 images) and applied a preset and then discovered B (6 images, 4 of which are the “same” images as those in A).
The first 4 entries are from A and the next 6 from B.
This is the DOP created for the first image in A and the “yellow” marker shows the Uuid that must match.
But if that DOP is copied from A to B for this image then there will be a clash between the database Uuid for the “same” image in B (shown in green) with the Uuid from the DOP copied from A to B.
The result will be that the edits in B will become the [M]aster and the edits from A (carried in the DOP) will become [1] (a Virtual Copy) and a new DOP will be created about twice the size to hold the data from the [M]aster and FC[1].
This explanation is intended to help but if you need additional information please ask. The actual problem is easily encountered but difficult to rectify and needs some additional features put into both versions of DxPL, along with creating full compatibility between the two releases (if possible) but …
EDIT:-
There is an alternative recovery strategy
- Copy the DOPs outside DxPL from A to B and if VCs are created then
for each VC do the following:-
- ‘Copy correction settings’ from VC[1] and
- ‘Paste all correction settings’ to the [M]aster
- ‘Copy metadata’ from VC[1] and
- ‘Paste metadata’ to [M]
- Effectively the [M]aster has become the same as the VC[1], i.e. the same as the image in A
- You are now free to delete VC[1]
- This must be repeated for all the DOPs in A that are copied to B (arguably this will not be necessary if you are able to delay discovering B until after copying to A and editing in DxPL and then copying the DOPs prior to any discovery of B by DxPL).