@JoPoV one of the most important things is whether you are running DxPL(Win) or DxPL(Mac) as my post identifier shows I am running a Win 10 system and any tests I carry our will be pertinent to that platform and may or may not be relevant to the Mac!?
The database is SQLite (like most of the other such software that uses a database) and as @platypus has stated relevant only to DxPL.
This may or may not cause issues please see This image cannot be processed since the source file could not be found ( After I cloned the Drive ) for a “similar” situation were some “cracks” were found! I will investigate those posts again to remind myself of the exact nature of that particular problem.
I think that it does but that may actually work against you just depending on the workflow that you want to employ?!
There have been requests in other posts on the forum asking for a similar feature! My concern is that it potentially adds even more issues with drives coming and going because now there is a DxPL database doing the same!
I actually believe that DxPL can handle even the same (named) files, in the same (named) directories on two different drives connected at the same machine connection with the same drive letter! But as @platypus has stated there are potential issues and the DOP and any Xmp sidecar file are all that is at your disposal!?
‘Projects’ cannot be dumped out and read back in so they will remain in the database in which they were created!?
So I decided to try an experiment as follows
-
Database hosted on a “normal” drive, the E: drive in my case which is my “extension” to the C: drive, both of which are SATA SSDs.
-
Files on “identical” USB3 connected drives, i.e. same named files and held in identical directory structures. Drives were “old”, smaller SATA drives connected via USB3 to SATA convertors, labelled “VERTEX 4” and “INTEGRAL 2” to create a potential “worse case” scenario if any confusion is to exist!
-
Started to experiment on my Win 10 system! The files were two JPGs and 3 RAWs and they were “discovered” in PL6.2.0 in the order “INTEGRAL 2” JPG then RAW followed by “VERTEX 4” JPG and RAW.
-
Create 6 projects that contained
1 INTEGRAL 2 JPG and
2 INTEGRAL 2 RAW,
3 VERTEX 4 JPG and
4 VERTEX 4 RAW and
5 all JPGs and
6 all RAWs,
i.e. 2 pairs of ‘Projects’ (4 in total) specifically with only files from one or other of the two drives and 2 projects which contained mixtures from both drives!
The database ‘Items’ structure with all 10 files having been discovered:-
The ‘Folders’ structure showing how DxPL manages “transient” devices:-
The ‘UniqueId’ is related to the Volume Id. of the device and controls how DxPL “matches” the directories (folders) on the device with entries in the database, i.e. not just by drive letter but by the “Volume id” ('UniqueId) I believe! Please note the designation of ‘EFDOPVolume’ for these entries in the database.
The 6 ‘Projects’ to be used when a device or devices are absent and are re-discovered to see how DxPL handles such a situation:-
By using ‘Projects’ it is possible to check if DxPL is handling the “original” database entries for the directories or rediscovering them anew!?
The two devices with the “identical” images in the “identical” directory structure:-
What happens when a drive is “missing”:-
There are warnings but nothing particularly dramatic, at least not during my testing!
The database after the drives have been disconnected, re-attached with different convertors and “forced” to have different drive letters!!:-
To stress DxPL “a little” I changed to older convertors and forced the attachments to be assigned different drive designators and everything worked as it should, I am glad to say!
This test was with a database not co-located with any images because the images were mounted on removable devices. If you start co-locating with the data (not really a problem) but using removable drives then there will always be issues when the database you were using is not to be found because the drive is not attached.
At that point DxPL will create a new database and place it in the default location and you will then need to switch to the database on the drive which is actually attached!
With respect to copy/moving files between the drives then the danger has been covered many times in the forum under the banner of “Unwanted Virtual Copies”. This can occur when the following situation is encountered
- DxPL is encountering a directory (folder) which has exactly the same name as one already in the database. As the above tests have shown that must include the ‘VolumeId’ (or so my tests seem to show).
- The Uuid in the DOP of a file already in the database (on the same Volume, with the same hierarchical structure) must match the Uuid of the DOP otherwise the “new” DOP data will be added to the database as ‘Virtual Copy’ [1] and the original database entry will be designated as [M]aster!
It is for this reason that I deliberately set out to make the structures on both the test SSDs identical so that I could test to make sure DxPL(Win) did not get confused and start creating unwanted VCs.
Before I try testing any further, i.e. adding the databases to each SSD I would like more than a set of “wishes” that seek to allow you to make decisions about you work flow later, I guess that you may want to move the drives between systems?
So please try to target my testing to what you believe is the most likely workflow that you want to adopt so that I can try to replicate that as closely as possible, if I feel up to testing any further! The testing takes a little time but the write ups take a lot longer (and the re-tests when something unexpected goes wrong!).
I have two near identical systems which I can use to test a scenario that involves moving drives between systems where there is a real danger of “Unwanted Virtual Copies” and moving files with the database between systems where there is …? I tested that situation some time ago but was unaware of the ‘VolumeId’ at the time so those results are extremely suspect!?
Regards
Bryan