The reason for the problem (a more detailed discussion will be added later) is actually now part of a FAQ on the DxO site i.e. https://support.dxo.com/hc/en-us/articles/4733212348573-Why-does-DxO-PhotoLab-automatically-create-a-virtual-copy-of-some-of-my-images-…
This isn’t a “bug” so much as a consequence of a feature but it has been seen that way (as a “bug”) by many users for a long time.
On my Master machine I created a test directory of 4 JPG images and “created” DOPs for them using the ‘Files’/‘Sidecars’/‘Export’ command on my Main machine (F: drive - running PL5.2.1).
I copied the files and the DOPs across to my Test machine (mapped as the V: drive - running PL5.1.4) and opened the files and made a simple but obvious edit to all images.
I had wondered if the DOPs would be imported on T with the same Uuid from the (original) DOP but the result was that a new Uuid is allocated on T and used so the images cannot come back from T to M with the edits in the DOP without the inevitable Virtual copies!
The following works as a work-around for this problem:-
The new directory copied from T(mapped as V: drive) in Beyond Compare to “<>-NEW” and opened in PL5
The original directory renamed (with PL5):-
The “NEW” directory renamed “back” to its original name with PL5 to complete the switch:-
The original directory can now be deleted at my leisure!
It is that complicated to move data between systems and avoid Virtual Copies (“swing” space is needed because two directories will be in the database and on disk at the same time)! Generally this should not be much of a problem but will be a nightmare with huge directories.
Unfortunately PL5 does not have functions like copy and paste but at least has ‘Rename’ and ‘Remove’!
If you look at this post I wrote above at Rotation not kept in dop’s why? - #67 by BHAYT (also included above) you will see me undertaking the very procedure I recommend (slightly different actually but both are about adding the new version, moving the original version to one side, slotting the new version in place (with the original name), and then, when you are sure everything has worked O.K., deleting the original version (as and when it suits you or not!?)
There is obviously a shorter process that could be used namely deleting the original and adding the updated back with the same name as the original but there is a risk that PL5 with simply see this as the current process that is causing the VCs plus I like the “security” of have the old and the new available until I am happy that the swap has been successful.
Doing the operations of renaming and removing within PL5 means that the database can be adjusted directly rather than by PL5 “discovering” that a directory has gone. i.e. it is important to undertake the renaming and removing from within PL5 to avoid any issues and it has worked every time I have done it this way!