@saint-112 Nick I am profoundly glad you sent us down a rabbit hole because of what I discovered in the process!
So one last point worth noting I believe, a lot of my time since the release of DxPL 5 has involved the problems with “unwanted” Virtual copies in one form or another. Typically created when a user enters images on one machine, takes them to another to continue processing with a better screen and faster graphics card and then returns them to the first machine.
If done carefully, as I proved recently, then all will be O.K. but many times that has resulted in the creation of a VC where VC[1] holds the latest updates and [M] needs replacing but while it is easy to locate (filter) and delete VCs, trying that with the [M]aster is going to result in the loss of all data!!
Fixing the images one by one using the procedure is time consuming when an entire directory is involved.
The alternative is another procedure I documented which involves changing the name of the original directory to e.g, -OLD and introducing the returning image complete with DOPs as and then deleting -OLD when the user is happy with the swap!
So I devised a little test to confirm my worst “fears”, i.e. that none of the grief that has been caused by the [M]aster was actually necessary!
- Four JPGS set up and discovered in DxO 11
- Set the ‘Rating’ (‘Rank’ in DxO 11) and close DxO 11.
- Open and modify the Uuid of the 4 DOPs (to deliberately create unwanted Virtual Copies)
- Re-open DxO 11 and we have
- There is no command to filter on [1] or [2] available in DxO 11 so select all the [1] one at a time to give
- ‘Remove’ and we have
So I and others have wasted huge amounts of time handling queries about “unwanted Virtual copies” and proposing solutions all because some “clever” person(s) at DxO “destroyed” a perfectly good design and replaced it with the biggest pile of … on the planet!
Actually that is probably a “slight” exaggeration but the change in design has caused an inordinate amount of grief for no real purpose.
The whole design for the handling of Virtual Copies that centres around the way the [M]aster is handled is a BUG, a wholly unnecessary bug (albeit there might have been a sound reason behind it that I haven’t fathomed because I don’t have access to the code).
The [M]aster has made us all “slaves” to a distinctly wrong design @DxO_Support-Team @Musashi please release us from this as soon as possible (but do discuss it with us before you do and check and share with us any hidden reason why it should stay - an opportunity to establish co-operative communication rather than the rather one-sided … we have today)!
@platypus I would suggest that it is a bug but one that might not be easy to fix and one that I don’t think occurs in Win 10 but I would need to run the tests again just to be sure!
PPS:- In one of the discussions the issue of the complications of real Virtual Copies versus “unwanted” Virtual copies was raised, e.g.
-
On the first system (a laptop), VCs might be added to the image before transit to the desktop system.
-
The images and DOPs will be imported into the desktop system for further processing where even more edits may be added, i.e. more Virtual copies or single copies acquire edits before returning to the laptop.
-
Iff (if and only if) any of the Uuids are not identical to the original system (if they ever existed on that system in the first place) then “unwanted” VCs are going to exist alongside intended VCs and the very best of luck handling that one. The safest approach might be the rename/replace/delete approach but that automatically means that ‘Projects’ on the originating system can have links “broken”!?
This issue only exists when the DOPs are taken into System B and allocated new Uuids. When that happens there is no hope of just carrying them back to the original system without “unwanted” VCs.