@John-M, @platypus, @Joanna. @sgospodarenko
Shared directories in a shared database do not work because the PL5db stores then as separate entries but the DOPs then overwrite each other and … chaos and an abundance of Virtual Copies.
The tortuous workings out that led to this “obvious” conclusion.
I have always thought that the test where A (main) hosts the Photos, DOPs etc. and the database and B(Test) accesses the Photos etc. across the LAN and is configured to use the same database as A should work. I have tested this previously and then again last night/early this morning and got Virtual Copies.
Hence, answer to your question, both machines are reading and writing DOPs and after the initial parts of the test I start getting Virtual Copies.
I need to test again with multiple snapshots to make sure both machines are “reading from the same hymn sheet”.
Then I need to see why there appear to be “clashes” between the database and the DOP (other than the obvious - that I have not got the setup right) particularly in light of the Sata SSD test which appears to work. Other than a BHT error the main difference is complete separation of the two environments, i.e. T is either attached to A or B not A but B can still see A but why would that make any difference.
Thinking about it ----- the Sata Test has both A and B seeing the drive as T:, the Lan test has one seeing the drive as F: and the other mapped as V: but … I need to attach the Sata SSD to A, share it across the LAN and configure both machines to access the database on T: and repeat the tests, starting with T: photos in their current state with DOPs and then add another directory with just Photos and check out as many scenarios as come to mind, snapshotting all the time and making sure only one PL5 is active at a go.
If the tests fail I may have to upgrade T to 5.1.3 but I will do that only as and when!
I actually ran the test below and now believe that there are two sets of entries being stored in the database and the writes are back over the same DOP!
Hence, Virtual Copies are inevitable because PL(A) and PL(B) are sharing the same database but not the same entries for the “same” files but they are then overwriting each others DOPs and therein lies chaos!
The chaos on PL5(B) with the directory from the original test.
Test Scenario:-
- Configured sharing on T: attached to A
- re-configured PL5(B). i.e. database on B, to be T: on A
- Restarted PL5 on B and navigated to photos on T(mapped to T: on A)
- Navigated to folder and all O.K.
- Changed an edit on first photo and closed PL5(B).
- Opened PL5(A), checked using database on T:
- Instant VC on all photos in the test directory the first photo shows original as [M] and the change(B) as [1]. The others have [M] and [1] the same.
- Set up more test directories on T: with only photos present
- Opened and closed PL5(A), no DOPs created
- Opened PL5(A) and forced DOPs on all photos and closed on A.
- Opened PL5(B) chaos with test directory from above test.
- Navigated to new directory and forced DOP export.
- Closed PL5(B).
- The DOPs do not match so VCs are assured!
- The database shows entries for the drive being ‘local’ or ‘network’!!