This is a problem that I have experienced from time to time when testing because of my re-use of the same image and associated DOP in test after test after …
I once thought that the error occurred only with directories at the same level in an hierarchy so some time ago set up various levels of directories and undertook testing and reproduced the error which appeared to be easier to recreate after deleting images from a directory and then adding them back!
I recreated the hierarchy today but with only one image per level and the same DOP per directory and went through each directory in turn with an empty database and PL5 performed exactly as it should allocating new Uuids to each and every “duplicate (identical)” image (with “duplicate (identical)” DOP) as it was encountered, i.e. no Virtual Copies - please see Unwanted virtual copies - #86 by BHAYT for an explanation of how unwanted Virtual Copies can happen!
The following test shows what happens when an image already in the database has the original DOP replaced with a DOP with a new Uuid .
I then deleted one image using PL5 and added it back in from the baseline copy I had made and up “popped” the two (?) Virtual Copies I had encountered before! Given that no image exists in this directory then the new (but copied) image should have been allocated a new Uuid and no VCs created!
I then created a new empty directory and navigated to it in PL5 and added the image and the DOP and the problem occurred again!
So the circumstances for the problem are that a DOP with an already in-use Uuid (i.e. in the database) is added to a directory currently “in focus” in PL5!
To test the theory further I created a modified DOP for another test image, i.e. containing the Uuid of the original image and, while PL5 had the new empty directory in focus, I copied the image with its modified DOP into the directory and encountered the two additional Virtual Copies!
When does this occur:-
- An image needs to be in the database
- Another image with an in-use Uuid, probably a copy of the original with its original DOP, needs to be copied into a directory currently open in PL5
- The result is not one but two Virtual Copies.
How to avoid:-
Simply navigate away from the directory into which images are going to be copied because the “new” image discovery code appears to work correctly!
Any possibility of this occurring in a “Real-world scenario”?:-
Could this occur in a real-life situation, possibly but only if transferring images back from a laptop etc… If any of those images contain Uuids from the original database into which they are now being copied and the directory into which the copy is happening is currently open in PL5 then I believe that VCs may result!
I wrote a procedure Synchronise PhotoLab - #26 by BHAYT to provide a “safe” means of transferring (merging) data back after a field trip back from a laptop into the main PL5 system.
Providing the target directory is not open in PL5 when copying the data into the target directory there should be no risk of encountering this problem, it will only occur for images that retained the original DOP (actually the Uuid in that DOP) throughout the round trip to the laptop and back anyway, and only then if the directory is open in PL5 during the import process!
Should the problem be fixed:-
It has probably been in the product for a long time but should be fixed @sgospodarenko and still appears to be present in PL6 EA4.