I was going to suggest that as a “cunning” plan!
DxO have a similar ethos when it comes to implementing some of the easier fixes they could implement, resources are finite but …
Basically when users have copied images and sidecars, xmp and DOP, from one system (A) to another system (B) they have been able to add them to the DxPL database on that system (B) but when they try to bring them back to A (“round-tripping” the images with the latest edits) they are greeted by DxPL adding the latest edits as Virtual Copy [1], hence “Unwanted VCs (in the bagging area)”.
The ‘Virtual Copy Topic revisited …’ was exploring how often this happens, given that I had worked out the mechanism that caused the issue, namely the Uuid held in the last part of the DOP.
Actually every user created (or system created) Virtual Copy will have a such a Uuid and these Uuids must be unique for every image ([M]aster or [VC] ) within a database!
Early reports seemed to indicate that this seemed to happen all the time i.e. any sort of “round-tripping” was going to result in VCs but the research for that topic seemed to indicate that DxPL used the original Uuid unless that Uuid was already in-use in a database!?
If my research was correct then copying and adding to another database on another system is possible and so is bringing the updated DOPs back to the first system, more often than not!
‘First Discovery’ is simply a shorthand way of describing the situation of “automatic import” used by DxPL when it encounters an image in a given directory that it has never encountered before, i,e, a first for that database or a “new” to that database image is “discovered”.
DxO changed the way they handled DOPs part way through PL5 releases but implemented the change in what I consider (not that I or my opinions should count for anything) to be a very clumsy way and the “round-tripping” or repatriation as I have also referred to it elsewhere can fall foul of the “rules”.
This Unwanted Virtual Copies and Moving DxPL edited images (DOPs) between System - Revisited - #18 by BHAYT references another topic in which I looked at the “first discovery” rules and their implications for handling metadata from either the image (embedded or xmp sidecar) or from the DOP.
Basically the the rules that govern whether DxPL detects external metadata changes and reads (embedded for JPG, TIFF and DNG and sidecar or embedded for RAW) and writes (embedded for JPG, TIFF and DNG and sidecar only for RAW) updated metadata from the image also controls what DxPL is going to do on ‘first discovery’!!
Please see attached 2022-12-20_092626_10-7.zip (1.3 MB).
I did some testing on this way back, i.e. accessing across the network, but before I understood the implications of the UUID in the ‘Folders’ structure which means while a user thinks things are working DxPL has simply imported the images again and any existing projects will fail and those “imports” will be subject to ‘first discovery’ rules and …!
I currently have three machines under my desk, with a bit of room for my aged legs, warm in Winter but too hot in summer (on some days), all connected via a gigabit LAN, which is how I do synchronisation.
This post has taken my allotted time for the day, I am trying to stop an old wooden lean- to from rotting completely and giving it a new coat of paint before the weather breaks! Will try a test when I can!
PS:- Networks are handled differently but your proposal is to copy the database from one machine to another please spell it out for me so that I can recreate your exact process between my two machine (System 2, - still my Main Machine and System 3 - my Test machine)!
The snapshot shows two mapped drives, one on my main machine (Mediasys) and the other on a NAS (DS220J) being accessed from DxPL6 on my Test machine versus a local drive (F:)
