Again and again DxO Photolab is creating so called, totally unnecessary “virtual copies” and by the confusion to delete them i lost a bunch of really nice fotos. So i want to know now how to disable this malfeature once and forever and get rid of all unwanted virtual copies SAFELY. Otherwise i will not upgrade to 7 and go back to Lightroom…
Unless you are moving files from one location to another outside of PhotoLab, virtual copies are only normally created when you expressly create them.
If you say you are losing images when you delete them, it will be because you are deleting the master (marked M on the thumbnail). The manual is clear on this - numbered copies are virtual, deleting the master deletes the file.
But you can always retrieve them from either the trash, Time Machine on a Mac, or your regular backup.
You do create regular backups, don’t you?
5 Likes
@Joanna That is not the only way to get VCs I am sad to say! The following snapshot shows PL6.10 alongside PL7.0.1 on my Win 10 system
I opened the image on PL6.10 first and made no changes except whatever the ‘Preferences’ added (6 - Neutral colors’).
I then opened the image in PL7.0.1 and made a change to the ‘Smart Lighting’ (final value = 55) which appeared to make no change (lighting was good anyway) and no VC appeared at that time and the ‘Preference’ setting for PL7.0.1 is
I checked the DOP and it was and still is set as 6.10, i.e.
I changed the Tone Curve in PL7.0.1 and wound up with a VC[1] where the [M]aster is the PL7.0.1 values of Tone Curve and Smart lighting (=70) and VC[1] is the PL6.10 edits!?
When moving between systems the normal state is that [M] is the original and VC[1] is the later image that has returned from the other system.
If I remove the image [M]aster in PL7.0.1 I will lose the image completely, both copies are “sharing” the same image.
1 Like
Sadly, not true on Windows.
This has caused me some grief as well, when moving from one computer to another. I work around it by always removing the database before starting PL, but there should be an option to disable the behaviour, so that it works as on Mac.
Edit: Beware that there are features that live only in the database, that aren’t written to dop or xmp sidecars, so be sure that removing the database is something you can accept before doing so. (On the other hand, features that live only in the database are of limited use IMO, since they can’t be migrated to another computer.)
1 Like
I’m not able to replicate this.
Wonder what might causing it for some but not everyone.
@asvensson I have successfully moved between systems, i.e. round tripped images with no problems (or so my testing seemed to show) but with both systems on the same release.
Going from editing with PL7 back editing with PL6 with a DOP in tow should simply result in the PL7 DOP being ignored by PL6.
Going from PL6 to PL7 should result in the PL6 DOP values (edits) being adopted by PL7.
But going from PL7 to PL6 has two potential scenarios
-
A bit like my case above where effectively you go from PL7 to PL6 and then back to PL7
-
Or you revert to PL6 and do not take those images back to PL7. Any edits in PL7 will be ignored in PL6, i.e. the PL7 work will be ignored.
But that has two variants
a. depending on whether that image was previously edited in PL6 and already exists in the PL6 database
b. The image is new to PL6
I will try to test the variants later today but if a user is testing a new release then the old release DOPs should be secured before any testing on the new release just in case the decision is made not to actually purchase the upgrade.
With respect to your edit then on Windows ‘Projects’ will be lost by starting with a new database and on the Mac I believe that ‘Projects’ and ‘Advanced History’ will be lost.
@Required are you referring to @Kit’s original issue or my “clumsy” test which needs to be repeated properly?
Update 1:-
- New database, new directories initially with 1 image.
- Made changes in PL6.10
- Opened PL7.0.1 after changes made in PL6
- The DOP changes to become a 7.0.1 DOP
- Changes made by PL7 are ignored by PL6 (expected behaviour)
- Changes made by PL6 are seen in PL7 (“expected” behaviour)
New image added to directory while that directory is open in both releases at the same time
- Changes made in PL6 cause a VC to be created in PL7 where the original image becomes [1] and the new changes become [M]
The following is a snapshot of real time windows of the thumbnails and the database entries with PL7 first and PL6 second.
This is an “extreme” situation because the same directory is open in two different versions of DxPL(Win).
The DOP for the newly added image is
I never created intentionally any virtual copies and yes i also use daily backups which get deleted after two weeks bcs i do not have the unlimited space to backup 200.000+ RAW fotos eternally. (Btw. i am IT Sys-admin with 30y experience) And also the trash bin on my NAS is deleted every 2 weeks for the same reasons. And when i needed the next time one of those accidently deleted photos, the 2 weeks were far passed. I see you try to turn the fault on myself but without those unwanted virtual copies i wouldn’t have that problem ! And since many people already complaint about problems with the virtual copies it is on DxO to give us just a clickbox in the settings to turn the whole “virtual copy thing” OFF ! It could be so easy…
differential backup will save “IT Sys-admin with 30y experience”
I’ve tried every way and by followin gevery description but I can not recreate the VC duplicates. 
Are you on Windows? It’s not issue on Mac.
Which prompts me to ask why on earth you are using Windows instead of Unix-based Mac? I used to have a client with several Windows-based computers, which I would go in and “service” almost every week - a nice little earner for me. Then, one day, two motherboards went down at almost the same time.
Having recently moved to Mac myself, I suggested they consider the possibility. They agreed and I set up a full office system. After a month or so of “It’s different, let’s go back to Windows” they started to realise that they no longer had to keep on calling me in and that the computers “just worked”.
So, I lost lucrative maintenance visits, but ended up with a very happy customer.
So, buy a bigger disk - they’re cheap enough. And, are you saying that you have 200,000 images that are all perfect and should never be destroyed? That works out at around 274 images per day, every day, 365 days per year, for 20 years.
The system and software doesn’t delete anything without your say so. It is well documented that deleting the ‘M’ copy is destructive. Avoid that and you will never lose photos.
Apart from that, read the article that @asvensson has posted and file a bug report.
@asvensson The clue is in my post header I believe " BHAYTBryan [WIN10, PL6, VP4, FP6, G9 & EM1 Mkii, RTX 3060]PhotoLab EA member"
@Required It is possible that it is a Windows thing or that I have got something wrong, except that the snapshots are of live windows not from snapshots patched together.
I used that method deliberately to try to ensure that I was being as accurate in my reporting as possible.
It must be remembered that this particular scenario is unusual but a variant of it occurred to me recently, possibly without both versions being active on the same directory (??), with images with 4 user VCs and I wound up with 8 VCs (which would be a mess if I had to sort that out for real).
It is this latter situation that I need to export because I was not seeking to create even more VCs in that scenario.
@Kit I am sorry you have fallen foul of one or another of the “Unwanted Virtual Copies” scenarios.
DxO does not differentiate between a user created VC and a DxO created VC, at least not as far as I can tell, and certainly does not give any clues as to which is which in the UI I believe.
With regard to what you were doing when you encountered the “Unwanted VC” can you provide a little more information and what action resulted in the loss of the [M]aster image. In my scenario above PL7 has “swapped” the original image to the VC[1] position, something I have not encountered before!
PL7.0.1 appears to be treating the PL6.10 DOP as the lead and is detecting the PL6.10 changes and updating accordingly
But deleting the VC[1] in PL7
doesn’t result in the loss of the original image. in this case
But we now have a slightly “odd” situation!?
Probably history I suspect, while I am glad about your experience with your customer and my youngest son uses a Mac for his video editing business I and my oldest son (and his son and daughter) use Windows systems as does the architectural practice he works for!
Not entirely true, they have been increasing in price not decreasing albeit my problem is that I have three machines to upgrade so that they can act as backups for one another!
@Joanna where is the sympathetic @Joanna of the past.
No-one, including me, has asked exactly what happened!
My question was to @Required. At least I think that’s who I replied to. 
Just odd that he can’t reproduce anything if he’s on Windows.
@asvensson there is no indication of who you replied to in the reply but @Required has a designation of M1 which I believe is a Mac.
But possibly not if he is not on Windows but it would be a slightly weird difference between the systems except if there is no clear guidance as to what should happen in such a circumstance and the software engineers are left to make whatever decision they feel appropriate!?
The forum seems to show a reply to a post that it doesn’t directly follow in a dropdown under the post replied to, and not if if the reply directly follows. Not blazingly obvious though.
If he’s on Mac then it’s no surprise that he can’t reproduce anything.
That automatic virtual copies is a Windows-only feature is yet another inconsistency between PhotoLab on Mac and Windows. (And the point is that it’s documented as a Windows-only feature.)
That is why I typically use someones identifier whenever at the start of the first reference to them in a post @asvensson (notice what I did there!)
In fact I have quoted text from a post and had the forum software remove the quote because my post immediately follows the one that I am quoting !!??
I do not believe that is true because the UUID issue that indicates that a DOP has returned to a system with a different identifier should cause some reaction on both systems (Win and Mac) or so I believe?
The link I pointed at earlier in the thread documents the behaviour as Windows-only. Makes no sense that DxO deems it necessary on Windows but not Mac (the behaviour causes more problems than it solves IMO), but I’ve never seen PL on Mac create virtual copies in the same way.
It’s called “incremental backup”, i use it but it’s anyway deleted after 2 weeks. And i do not have to set up an eternal backup bcs a software is buggy. Or the software get’s fixed or i change the simply the app. Your comment is as useful as a pimple…
One i dea i have is that i have all the pics on a 70TB NAS (Synology, Linux) and somehow creating date of files is changed in some cases. It might be the reason for PL to create VCs without asking. But to confirm i would need help from the DxO developers. Anyway it would just be enough if we could just have a choice…to disable this “functionality”…