I had a plan, but I don’t now think it can be achieved so I thought I would check it out here.
I presently use Windows on both a laptop and a desktop and whereas I can sync the images, dop and xmp files, I cannot sync the database so any user albums are not transferred across. So, I thought, I can get a fast usb ssd and put everything on there - job done and I can move it from one to another.
Time passes … I consider getting a Macbook and sharing the images between Windows and Mac. I think I have discovered that whereas Windows allows you to move the database location (in my case, onto the ssd), Mac does not. So that rather seems to scupper the plan. Is this right or is there a way that I am ignorant of?
(@roadcone) Clive I am a Windows user but I believe that Mac users have stated that the database is a “fixture” on Mac systems. So moving the database via the USB drive would only work if you copied it to the correct location.
I believe that I have done tests that prove that can be done, either simply or using a ‘Mount Point’, I haven’t the time to go digging to find out which. But I only tested on Windows machines!?
However, I have no idea about the compatibility of the two databases, the layout etc. that might make any sharing of databases between Mac and Windows systems a non starter.
We need input from DxO (@Musashi) about any such compatibility issues and if they are insurmountable we need some way of moving projects between databases (on Win, on Mac and between the systems).
PS:- we need that capability to secure projects to allow them to survive a database “loss”, accidental or deliberate.
all depends how you format your ssd drive.
on your Mac you can format APFS which also work with Windows. if you are to put your drive with “case sensitive” and “encrypted” i’m pretty sure only Mac can read it, as when i had it plugged on my pc laptop, my drive was “empty” according to windows but i had my mac backup and a folder with some movies in it.
so new mac format for portable drive are now APFS which supposedly does a better work at preserving your files. there used to be 3 format but 2 were not compatible with Windows.
so format your drive APFS only, no emcryption or case sensitive. you should be able to drop and drag folders between Windows and Mac.
You could create a basic database with a few directories and image and projects and post it here and see if a Mac user is prepared to load the image into the required directory etc,
do it the other way round and specify what the database should look like and get a Mac user to upload a database which we can test!?
Providing it is possible to get a compatible format for the USB and the database would have to be copied from the USB drive into the Mac location and then back again!
I had thought about getting a Mac mini rather than a graphics card, which then turned into a motherboard, memory, processor and cooler as well as the graphics card! However, I can use the new PC on all the software I have acquired over the years and feel that it was the more sensible approach even in the Mac version of PhotoLab has features I considered as desirable.
seem yes you need a 3rd party to read APFS.
format your drive from Windows in NTFS, mac still read those, i have some drive still running it. you just can’t format new drive in that format from mac, unless your drive already few years old.
I’m not surprised the databases aren’t compatible. There are enough differences, like history saved in the database across sessions on max and not on windows that I believe the structure is different.
Also there’s the whole problem that the database image file index is dependent on the serial number of the hard disk where those images are stored, it’s unlikely the database itself will ever be transferable across platforms.
That said, aside from information about cached images, and a cache of the data available in a DOP and or the metadata of the original image file, the only thing that I can tell that’s kn the database and not in the sidecars is information about an image’s project membership. (And the advanced history info.)
You can vote for adding project info to the DOP file here. This would make it relatively easy to maintain to separate databases on different machines and still be able to go back and forth from machine to machine to edit as the sidecars will have the edits (assuming you have the sidecar settings correct on both machines.)
@MikeR While it was obvious that compatibility was unlikely but just accepting that without testing was a wasted opportunity. The issue of the “advanced history” is nothing compared with the fact that the database file naming does not tally, neither do the field names which all begin with a “Z” in the Mac version, but not in the Windows version.
I have seen this with the databases of other products but in their Windows incarnation.
Agreed but that particular issue is an easy one for DxO to remedy (which means we might wait for 5 years instead of 10!). I actually encountered the issue with digiKam 8 yesterday (sorry I never posted this item when I wrote it so "yesterday was about 5 days ago).
I first started playing with digiKam many years ago and investigated it again during the PL5 Beta testing but found that the Windows version couldn’t do something I “needed” which was only available in the Linux version at that time!?
A recent DxO forum post encouraged me to re-visit the product, at the same time that I discovered that IMatch had undergone a major upgrade, if I cared to pay for it! I did pay for the IMatch upgrade but also upgraded digiKam to version 8 and encountered a problem when I opened the product and was confronted by disk number issue!?
The reason was legitimate because I had upgraded my F: drive from a 6TB drive to an 8TB drive and by copying files not by attempting a clone, i.e. the disk number (UUID in the ‘Folders’ Table) had changed!
However, digiKam just offered to continue using the files on the “new” F: disk, whose directory structure matched that of the old disk, rather than just accepting the situation and starting over by importing all the “new” images (again, invalidating ‘Projects’ in the process).
That particular “fix” to DxPL is trivial and if digiKam can do it so should DxO @Musashi!!
Lightroom produces a dialog, when something has gone missing (move/rename/delete) and asks for action. It can then either change the respective DB items to fit the new situation or remove the items from the DB (without moving anything to the trash)…