I just responded to post on the ‘Unwanted Virtual Copies’ topic but had intended to start a new topic until I found things were not as I seemed when I undertook some testing recently.
So I will go ahead with the topic revisiting some “old chestnuts” and issues that might still “plagued” some users!
@danwdoo Its funny you should ask that!
The issue has not gone away and what I wrote here is correct with respect the how and whey the problem occurs, i.e. if an image with a DOP is presented to a copy of DxPL that already has that “EXACT” copy of that image in it then a Virtual Copy will be created as part of the “re-absorption” process, i,e, as I stated as was demonstrated then if this Uuid does not match the database entry Uuid then the “new”, non-matching DOP will result in a Virtual Copy and frequently that copy will be the latest and the one you want to become the [M]aster!
The Uuid as shown in the following table (taken from a document I have not published that needs to be updated for PL6)
But as time has passed more things have become apparent when forum members have posted issues.
I was about to start a topic requesting that DxO provided some options when this situation arises, e.g.
-
Warn that the issue has arisen
-
Offer the following options
1 Ignore - make a VC from the new DOP data, this retains the current situation
2 Overwrite - use only the new DOP data, no VC is created
3 Make Master - Use new DOP data as the Master but retain old as the VC, the new DOP is the [M]aster and the existing DB DOP becomes the Virtual Copy
This requires some UI development but the code already exists and needs to be re-purposed @Musashi but implications need to be evaluated and checks and balances made to ensure users know and understand the implications.
The advantages of doing things this way is to leave all the internal references alone so that existing projects are not disrupted.
The procedure that some users have developed for themselves and the version I wrote for
- changing the original directory name in DxPL to -old,
- introducing the new versions as -new and
- when happy changing the name in DxPL to and
- finally deleting -old
is controlled, checkable and reversible right up to the point of deleting -old but no database pointers (references) are preserved and projects (if used) are “damaged”.
At the same time I started to investigate writing a Python script to swap the Uuids between the existing DOPs and the returning DOPs, effectively a programmatic way of of the above procedure.
To test the principle I recreated the problem and copied the DOP from the original DOP to the new revised DOP and opened DxPL (PL5.5.0) and it worked fine.
So I started to set up test data and repeated the exercise between my two system and discovered that the Uuids had not been changed. The receiving system did not change the Uuids when it added them to the database but retained their original values and so they retained to System A still matching the database and not a VC in sight!!??
Was this a new thing and on what release did it occur?
So I went back to PL4 and the same thing happened (or rather didn’t), no DOP change on System B when discovering the transferred directory so they came back to System A just fine.
So the potential for this working successfully has been there all along, DxPL must change the Uuid of an incoming DOP if that Uuid is already in use. During testing I am frequently clearing the database (deleting the db file) but I also reuse the same data many times and in my case there could easily be an entry in the database with the same Uuid if I haven’t cleared down the database before the test.
But why should this happen to users in “normal” circumstances?
So please conduct a test as follows:-
- Select some images, just the images with NO DOPs and put them in a test directory on System A as you would normally do for any files that are going to be moved between systems.
- Open in DxPL and make some obvious adjustments
- Select those images and put them in a DxPL ‘Project’.
- Close DxPL and copy the DOPs to a subdirectory for later comparison, e.g. “System A - DOPs”
- Use whatever method you are going to use to move the images to System B
- Open on System B and make some alternative obvious edits so that they have obviously changed
- Close on System B and copy the DOPs to a subdirectory for later comparison, e.g. “System B - DOPs”
- The DOPs can be compared at this point to see if the Uuid has changed. If it has then you can expect VC when those images and the new DOPs are “repatriated” to System A.
- Transfer the updated images back to System A via whatever is your chosen mechanism.
- Put them in place of the original images or simply attach the USB drive as it was originally etc.
- Open DxPL on System A and navigate to the directory and see what happens.
- Open the project created and see if the images are found as expected
Anyone who conducts this test please report back!?
If you regularly experience issues then please post exactly what you are doing that creates the problem!