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 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!
@platypus because I am testing and want to know as much as possible about the state of the files being copied I use Beyond Compare so that I know if the receiving directory is empty or use BC to create a receiving directory with a chosen name and then fill it with the designated images.
So for the initial test I used BC to copy from M(ain) to T(est} and then continued with a refresh after changing the images on T(est) and captured the Uuid differences (and other changes)!
For the “strategy” test I think I copied from T(est) “<…>” selecting all to M(ain) "<…>-NEW.
But my original strategy is slightly easier if the users doesn’t have access to a product like BC so
On destination system (Main) change the name of the target directory with DxPL.
Copy the original directory from the sending system (via a LAN using mapped drives, in my case) or via a USB stick or drive retaining its name (the original name).
Navigate to the newly copied directory on the target system and re-discover the original named directory
To check it out I did the copy in the opposite direction taking from Main to Test via a USB3 stick
Copied the original directory to the stick using File Explorer (I actually have about 6 additional File Managers and a FileMenu add on but I did it the “hard” way - copy and paste), dismount USB3 drive from Main and unplug.
On Test, open PL5 and navigate to “Test - 02” and change the name with PL5 to “Test - 02 - Original”.
Plug in USB 3 drive and copy “Test - 02” from USB3 stick and paste to the correct location on the mirror disk structure on Test using File Explorer
Navigate to “Test - 02” with PL5 (which was open all the time) all good and no Virtual Copies
But I missed the ease of the LAN and the convenience and insight of Beyond Compare but the procedure is just fine (if you have the space for two directories of images, DOPs, xmp sidecars etc), the temptation with Beyond Compare is simply to copy the changed DOPs etc. and the consequences will be Virtual Copies!
EDIT:-
@platypus As we both know the procedure I am suggesting is a work-around for other things that we have both asked for, in your case since December 2020 Database Maintenance in my case a little later than that since I only started posting in early 2021 during the PL5 Beta testing.
Essentially we (and others) have variously asked for the following in relation to this issue of using DxPL on two systems, e.g. a laptop while on field assignments and a main PC back at “base”:-
The ability to “clear” or “expunge” database entries for an image or a selection of images (it would be useful to add such a command to include an entire directory). This would resolve a number of issues that have been encountered from time to time and would make it easy to clear the way to re-receive images with updated DOPs that the user wants to replace images and DOPs currently residing on the system and present in the DxPL database.
A mechanism to “promote” a Virtual Copy to [M]aster status, either “swapping” the original [M]aster to VC[1] for example or replacing the existing [M]aster completely for one or more images or swap/replace the [M]aster with a designated Virtual copy! The mechanism should be able to handle a selection of images that contain only [M]aster (single images) i.e. by simply ignoring them while searching the selection for items with both a [M]aster and VC[1].
Manually “promoting” a Virtual Copy to [M]aster status (or swapping the [M]aster):-
Potentially create a copy of the [M]aster (just in case) by executing ‘Create Virtual Copy’
Select the desired VC[ ] for the swap and ‘Copy correction settings’.
Navigate to the [M]aster and ‘Paste correction settings’/‘Paste all correction settings’
Select the desired VC[ ] for the swap and ‘Copy metadata’
Navigate to the [M]aster and ‘Paste metadata’/‘Paste all metadata’
Verify that the [M]aster is identical to the VC[ ] before deleting the VC[ ] (and the security copy, unless executing a swap) as required/desired
What about Projects etc.!?:-
The detour strategy cannot handle projects etc. but currently they cannot be copied out of the database anyway (?)
I’ve been away for nearly a week and have a bumber of batches of image’s given a initial processing on my laptop with PL. They are weeded via FastStone Image Viewer (any jpg’s needed rotation done then)put through Photo Supreme 5 for keywords ) can’t do geotagging as no internet). I export as jpgs on the laptop to do a further weed and run through Photo Supreme to remove those removed.
OK, not this is where it should all go wrong, get home and copy bovver to my desk PC. All OK, add geocaching in Photo Supreme refine where needed image’s in PL and now using Deep Prime export again. On bigger/better monitor I always find some not worth keeping so remove them.
Again should be a problem, export back to laptop, run through Photo Supreme as now some weeding, changed processing and geotagging added. Open in PL and have it add geotagging via changed metadata. No problems no virtual image’s and as I use Photo Supreme sidebar data loading is off…
Now the changes DXO have made that should be causing me and does others problems.
I find it very appalling that they added this with no warning and no comment when many were posting of the virtual image problem. I also find it arrogant to create problems when copying image’s between computers, they licence more than one copy of PL so what do they think users will do? I can see copying to older versions may cause problems but between the same version even if not build its madness. The problem would be less is the stupid change to virtual copies hadn’t been made some years ago all you would have to do was delete the unwanted ones rather than the stupid process they created now.
@John7 I don’t know why your workflow succeeds and does not get any Virtual Copies because if I understand it correctly it should @sgospodarenko and for the following reason.
Every image in a DxPL database is assigned a unique number (Uuid) when implicitly “imported” into the DxPL database by simply discovering the new images in the the new directory, i.e. the user navigates to the new directory. This is also the case for any new images added to an already “imported” directory. Any changed images re-discovered in an already “imported” directory (e.g. containing adjusted metadata etc.) will continue to use the existing entry in the database unless accompanied by a new DOP (see 4 below).
The Uuid from the image allocated by DxPL is then copied to the DOP sidecar when one is created (after almost any edit) or when the user selects to ‘File’/‘Sidecar’/‘Export’.
All edits carried out in DxPL are updated to the database and copied to the DOP, including metadata changes but from PL5 the much increased metadata list will not be copied back to the [M]aster image from the DOP.
If the image file, any xmp sidecar file (for RAW images only) and the DOP are carried to another machine and introduced to a another copy of DxPL it will be “imported” with no problems whatsoever providing that the DxPL database does not contain a copy of that image with exactly the same directory layout already. If the second system has already got a database entry for the image (not just the name of the image but the exact directory structure as well) then DxPL will compare the Uuid of the database entry with the Uuid of the DOP and if they do not match then the existing database entry will become the [M]aster and the DOP entry will become Virtual Copy [1] to protect the image and the DOP data!
There is nothing “sinister” about this action it is simply one way of automatically handling a potential duplicate clash (the only problem is that I don’t fully understand why you don’t experience the same problem!)
The essence is DxO chose to ignore the way many customers use more than one device when processing images and did so with neither warning or way round the problem they created (even if it was a solution to another problem of incompatibility of different versions of PL). They created part of the problem with the change to virtual image’s some years ago making it much more difficult to use them. Without that change a user could select the image’s not wanted and selects on mass (not ideal but better than having to copy and paste if the newly created virtual imide is the ones wanted (and in my case (and I expect anyone using two devices) it would be every time).
As to why I don’t have problem, from what you say re numbering I have no idera as I haven’t deleted the database since coming home.
Change the name of the original image, e.g. when on the second system (that could be as simple as adding a suffix).
Change the directory on either system, that could be as simple as adding a suffix to the directory name
Do you transfer the updated DOP when copying the image back to the laptop.
Do you copy from the laptop to the PC or do you move from the laptop to the PC?
At what stage do you use Syncovery and what options do you use? Syncovery has a number of ways of copying files including ‘Block level copying’ although Syncovery should be able to detect that the DOPs on both system have a changed Uuid as I did with Beyond Compare which would make that a candidate for copying. I use Beyond Compare for my backups because it allows me to actually see and “understand” (hopefully) what is happening between the “Mirror” copies that I keep on mullitple systems before making any changes!
My biggest concern is that you are not actually transferring the DOP from your PC back onto your laptop!
Although users consider the issue I am describing here as a “bug” there are good reasons for the checks even if the outcome is not what users want or expected!
I believe that there should be a controlled way of handling the situation, perhaps the ‘Ask’ feature I described is the safest, i.e. DxO do not add a ‘Preferences’ option but leave that part alone and warn when a copy is going to cause a (potentially unwanted) VC situation and allow the users to specify at that point what to do @sgospodarenko, e.g.
Proceed as normal, i.e. the database is the [M]aster and the DOP edits are the Virtual Copy[1] or another (VC copy) number if there are already user created VCs present. With the following potential options
1 - Retain the new (DOP) edit as a new VC
2 - Discard the new (DOP) edit - unwise but !?
Reverse the order, i.e. the DOP edits become the [M]aster and the database entry becomes VC[1] or the next VC for the image. This is where things become messy because any existing user created VCs came from the database entry which has now been superseded by the incoming DOP version!? With the following potential options
1 - Retain the old database edit as a new VC
2 - Discard the old database edit!?
Allow the selection to be applied to each individual situation encountered or ‘All’ (effectively all such encounters in that particular directory).
Consider applying the option selected for ‘All’ such situations detected for the whole session!?
I use Syncovery it copies everything changed or missing over, set on Exact Mirror. PL for example on the laptop comes up with the add metadata when the geotagging is copied over and shown changes when they are done, so everything is going back and forth. But only where changed so for example Copy L->R D:\Photos\2022\06 June\Plas yn Rhiw_DSC1336.ARW.dop (11.5kB) Copy L->R D:\Photos\2022\06 June\Plas yn Rhiw_DSC1336.xmp (11.4kB) Copy L->R
But no RAW file
Others where the RAW filer is changed they go as well.
Yes there needs to be a way of controlling copies to versions of PL different to the one editing is done on. But not the shambles they have introduced now, but I do wonder how many users will have it as a problem. My wife uses a very old PL as she only uses a phone now. We would never use my PL for her editing not least that she finds the current interface difficult to use. From what I have seen others who do have the problem are using the current builds, so why on earth would that be a problem and should never be effected on transfer (a thing DxO should never have done). Indeed how far back it would be a problem, Photo Supreme warns users if the database is updated they will not be able to use data from this build on an older build. Is that not enough, or does DxO inability to protect changes between versions make it such a big problem. I know some run many old versions for editing compatibility but surly they are not adding images created on newer versions to the old ones they are running?
