@sgospodarenko Help requested not to fix a problem but to comment on a test which has me puzzled .
In my response to @John-M and @John7 in response to an original query from @Riverman I put together a list of ways that I had investigated to avoid the “unwanted Virtual Copies” situation.
However, in the light of my results for the test @ Cache file - #20 by BHAYT where the two directories were being held separately in the database leading to DOPs being overlaid and VCs resulting I was concerned why my test @ Cache file - #18 by BHAYT had worked!
i.e.
So I tested the situation and it continued to work even when I changed the drive letter on one of the machines, please note that the change of drive letter would affect the location of the database as well as the files!
While I am glad that this works and means that a hard drive containing the database and images and DOPs etc can be transferred from one machine to another I do not understand why PL5 is recognising the directory whether the drive is mounted as T: or Q: and realigning the database in line with that discovery?
Test Scenario:-
So the Sata SSD was already connected to the Main machine (A) as T: and a new directory was “discovered” and the Tag was set on all files in a directory to ‘Reject’ (‘Red’), PL5 was closed and the T: drive was also closed and detached from machine A.
The Sata SSD was then attached to machine B and PL5 started but that caused a problem because iPL5(B) was configured to access T: across the LAN. PL5(B) reset the database location to the default so the location was changed in the ‘Preferences’ to point to T: and PL5(B) closed and restarted.
Navigating to T: located the original database entries with the Tag set to ‘reject’. The noise reduction on the two RAW images in the test group were set to DeepPrime and PL5(B) was closed and the database showed that the drive was opened as Local Disk T:.
The drive on B was then changed to be the Q: drive and PL5(B) opened, it defaulted to the default db location, but that was then changed to the Q drive and PL5(B) closed and restarted. Navigating to the directory now on Q: still located the data that had just been on T: as hoped but not necessarily as expected - no VCs were created!
The database shows that the entry for Local Disk (T:) has been changed to Local Disk (Q:), therefore PL5 will pick up the old records!?
The Sata SSD drive was closed and detached on B and attached on A: and opened with PL5(A) on drive T: with everything intact and no Virtual copies!
and the database was once again showing Local Disk (T:)
While I am glad that this works and means that a hard drive containing the database and images and DOPs etc can be transferred from one machine to another I do not understand why PL5 is recognising the directory whether the drive is mounted as T: or Q: and realigning the database in line with that discovery?