Sometimes I open images in folder, which includes the *.dop files too.
The latest Photolab v8 still suffering from the additional VC generation by all visit of the folder. This is my last opening result:
Endre
Hi again, Endre ā¦
For the Win version of PL, thereās an option to Sort by VC number ā¦ which makes it easier to group-&-delete the unwanted copies.
John
Hi John,
Thanks for your advice. I never touched the sort order change. It was my mistake. The VC delete was successful.
Anyhow, to avoid the unwanted VC generation - I think - is a bug.
Endre
I never see this problem - because I donāt use the database (I delete it before I use PL).
I believe it arises when PL encounters a conflict between details contained in the db versus details (for same image) stored in sidecar/.dop file ā¦ in which case (for āfail safeā purposes), PL creates a VC in the sidecar containing the āalternative visionā from the db.
I use the database and never got unwanted VC so far (PL7, PL8/Win).
From PL8.0 Help ā Menus, Preferences and Functions:
Yes, in the following cases:
That is the point, John. I use DxO since ProPhoto v4.5 and always importing the latest database to the successor application.
Refer to Wlodek reply ( after tis message )
This is the case I follow. When I find an image in my source library and want to reprocess with the latest PhotoLab version, it is complicated to trace, which software version was the last processor. I just drag the image to the e.g. PL v8 Desktop shortcut and wait till the app start. Yes it is true, the original image consist the *.dop files. What shall I do ? Delete all *.dop files from the original image folder ? Or move ( copy ) the particular image to an empty folder for reprocess in the latest software ?
Generally, it is not clear, why PL generates new VC copies. What kind of data loss is expected ?
On the other hand, every opening such an older PL generated sidecar folder, generates additional VCs. OK if every new version add a single VC, but why all opening of the same folder with same PL version generates additional VCs ?
Absolutely discluded. Every PL version has its own folder for database.
Endre
Try opening the DOP file in a plain text editor. The creating version is noted at the top.
PL scans in the background whole current directory (EDIT: but not its subdirectories, as some asked for) when it starts and when you change the directory. It may also prepare thumbnails and preview images in the cache.
It seems this process was well tuned in PL8 compared to PL7, but itās still there.
A long time ago, I created my DAM software, which allows me to browse folder hierarchies, flattened, as if they were a single āfolderā At the time, I suggested such a browser to DxO - they ignored my suggestion (as usual). But, until you just mentioned it, I hadnāt thought of their methodology of background scanning and possible DB conflicts. So it seems like my idea would have caused even more chaos. Can you imagine PL scanning the entire disk, with files from multiple versions? 
Yes Joanna, if Iām looking for an image history, it is possible to identify. Normally Iām looking for a particular image in the processed image folder ( which is always independent from the source image folder ).
Have an image name ā search same name in the storage sources ā find and navigate there ā list with name in ascending order ā check the .dop file existence ā if yes, open and identify the version by the serial number at the end of the file ā trace the PL or DxO Optics version match to the serial number ā start the corresponding PL or DxO Optics version ( if it is not too old and the Windows PC is still working incl. the necessary OS to use ).
What is the other solution ? If PL or DxO Optics find, the .dop file is not compatible, simple neglect its existence and the user can start from scratch the editing. It is certainly less time, than go through the am identify process.
Endre
@Wlodek I believe the only difference that creates an āunwantedā VC is that the UUID in the database does not match the UUID in the DOP.
Every [M]aster and VC has an entry in the database in the āItemsā Table (the Mac has a similarly named structure) which is assigned a UUID, which is then copied to the DOP and exists here
Version = "17.1",
}
,
ShotDate = "2023-01-18T14:14:25.0350000Z",
ShouldProcess = 2,
Uuid = "DC74CF50-2AE3-40AB-AC9B-D7C2841B217E", <------ The UUID that is tested with the database entry
}
,
}
,
Uuid = "D7BB3DE7-D59C-452B-8B08-3C79F61C9A86",
}
,
Version = "17.0",
}
When the database UUID does noy = the DOP UUID for the same image name in the same directory then a VC will be created with the database entry as the [M]aster and the DOP entry as the VC.
For entries that have user created VCs then life gets even more complicated because you will end up with a VC for every original entry!
A potential reason for the mismatch to occur if the images copied back are not from the database now in use.
Because the earlier version will ignore the DOP from the later version completely and allocate a new UUID. If this entry now āround tripsā back to the original database for the later version of the product it will have a UUID mismatch, and a VC and ā¦
This occurs because not letting DxPL read the DOP means that it will be added to the database as a new entry with a new identity (UUID). If you then instruct DxPL to read the DOP then you have an instant UUID clash between the newly created item and the old DOP!!
It would have been āsmartā of DxO to code it so that it could be instructed to ignore the old UUID but what is DxPL going to do about the edit state of the new versus the edit state in the DOP, keep both of course so we have multiple copies, typically the [M]aster and VC[1] .
@Bencsi The whole point is that no edits are lost because they are contained in one or other of the copies! The users challenge is to determine which represents the most useful/accurate / ā¦ set of edits
The reason is as I stated above and no more nor no less but what is needed is the ability for the user to give DxPL a chosen strategy, e.g. use DB entry data or use DOP edit data and āonceā or āalwaysā repeated for every directory where the problem is encountered less than a days design and coding effort at a gues.
That should not happen unless you are introducing the same image in the same directory to a database that already has an entry for that exact image, i.e. same directory and same image but with a different UUID.
PS:- Having the same directory open in two copies of DxPL at the same time is guaranteed (?) to cause VCs instantly, even if one copy is on one machine and accessing via a LAN and the other is the host of the image directory.
Now, thatās where I work differently. I tend to export for a use and then delete the export after either sending or printing. If I want several versions, I will create VCs and rename them.
Although, now that I am using Topaz Photo AI for print sharpening, I find myself keeping TIFF exports from PL and, sometimes, from Topaz. in which case, I use my DAM to keyword them and either my DAM or Finder to search for them.
Or, by not keeping the final print export, it makes me ārefinishā it for printing, in much the same way as darkroom printing means a āhand-madeā printed version.
Hi Wlodek,
Iām not complaining the folder content trace process, rather the new VC generation without my intention.
The VC listing order in the filmstrip is useful, if I originally did not added VC to some of the images. Usually in a set of images there are few image need to make VC to process independently its versions. If PL add to every image ( having .dop file ) a new VC, it very complicate to filter my intentional VC to select.
I think, it would less problem, in case of .dop file incompatibility - simple neglect the .dop file content.
Endre
As others have mentioned, this can only be avoided by never mixing database and DOP files. I have opted for automatically using DOPs and scrapping the database whenever I am about to add images and their DOPs to my existing folder structure.
Oh, and never processing files in a version of PL that is older than the version mentioned in the DOP.
You just have to be very disciplined 
@Joanna Not very useful for those who want to have āProjectsā or retain āAdvanced Historyā on the Mac!
Hi Joanna,
As far as I can, I never mix the folder structure. Except, when my HDD went wrong, and I had to exchange ( using same folder structure, but DxO treat the new HDD as unknown and had to rebuild the link between folders and Project content one by one. Painful long job ).
Easy to say. When I load an image to the new PL version, the new VC copy need the .dop files to be updated.
By the way - just for test purpose - I did open same image in PL6 and PL8 simultaneously. It was trouble less. Both app read the .dop file. both app was able to read the .dop file, no complain about last editing version. The only difference was, the older PL6 did not updated the PL8 .dop file, it left unchanged.
Endre
This bother me too.
it would need to be able to āfold/unfoldā the VCs onto the master and have the number of copies displayed on it when folded.
@Bencsi That is a known issue and is the result of the drive identifier changing. DxPL treats Drive C:\ and drive C:\ as two different drives if they donāt have the same partition /Guid ide the same i.e. the serial number here becomes the UUID that identifies drives
I have written a procedure to help resolve this issue and published it in the Forum and have written a PureBasic program (incomplete at the moment) to help swap drive UUIDs.
Typically the newer versions of DxPL do not automatically update the DOP after its discovery, only if a new edit or an export is made.
Once the DOP has been updated to a new version it cannot be taken back to an old release because DOPs are not backward compatible. There is a trick to change the version field but that is only going because DxPL ignore edits it cannot understand!
If you do then take it back to an old release that already has that DOP in its database I believe that the UUID will remain the same and the DOP will be āhappyā with either release but I have not verified this.
However this is a simultaneous opening test PL6.18 versus PL8 and we have this after I made a change in PL6 (to the NR option) and went to the Customize in PL8
We are obviously not testing in exactly the same way!
What DxO does seem to have corrected is the runaway phenomenon I found in the past whereby one changed the DOP which was detected by the other and changed the DOP which was then detected ā¦ and so on albeit that was across two systems whereas the above test was on conducted between two versions but on the same system!
Donāt intend to derail the discussion, but is there now a way to ārenameā VCs?
@swmurray Iāll let a Mac user update you with respect to the Mac, where I believe it can be done, but not on Windows.
The VCs. cannot be moved or renamed and occupy the same position in the DOP as they do in the product, i.e. the [M]aster, is the first entry in the DOP, VC[1] the second entry and so on for each VC.
Some work I did with @platypus seemed to indicate that is not the case with Mac DOPs!?
So you cannot move DOPs in the order or āpromoteā a VC to becomes the [M]aster it all has to be done manually by copying and pasting the edits (and not getting hopelessly confused while doing so).
