I think the problem is not so complicated ( Win ).
copy all folders ( incl. the sidecars ) to any new location
Open DoP and visit all target folders one by one, if you want to check. All modifications will be visible
All folders will be additonally registered in the DxO database.
The problem is, DoP register any image individually on every location. It will be added to the database after DoP open the folder only. The sidecar existence became valid again after the folder will be listed in the Database.
Unfortunately, the History is not included in the sidecar !
Other people have already mentioned that History and Projects will not be available. I can live with this, some people may be quite disappointed by this weakness of the software.
I couldn’t find the PhotoLab 9 database. I tried in the location specified in previous posts from 2024: /Users/username/Library/Application Support/DxO/DxO PhotoLab 7/Database/
I have found it in /Users/username/Library/DxO PhotoLab 9/ along with databases for v5, v6, v7 and v8 - all taking up valuable space.
That’s the location the database has been in for PLX (X being 1…9).
With every major version (and some of the dot updates) comes a new database. It’s normally put in a separate folder for major versions and imports data (and residue) from previous versions or releases.
PL for Mac does NOT provide official means to relocate the database, but it can be done in PL’s .plist preferences file located in your user account Library/Preferences folder.
I’d advise against doing this in order to not add another risk to PL stability.
I wouldn’t classify that as a weakness - it’s more of an implication …
Resulting from Project and step-by-step correction History details not being stored in sidecar/.dop files … which, in the case of step-by-step History details in particular, is a very good thing: otherwise, sidecars would be crammed full of clutter.
Unfortunately, this did not work - the history for the moved images is still “Loaded sidecar” and the Projects are set to zero images each. I recorded the Z_PK value for the new drive (verifying the UUID with the one Disk Utility provides, and used it to update the ZPARENT. I deleted the cache in /Users/username/Library/Caches.
Projects can not be in sidecar (dop), as Projects not folder / individual photo based structure.
Regarding History i think it may not to much sense to store in dop.
Dop not necessary, that why the database is. However I sure most of us use the dop.
I never assumed the projects would be in the sidecar. I have decided the history is not that important to me. The main thing for me to do is to get my images into a real media organizer/image asset manager. Unfortunately nothing I’ve found is as good as Apple Aperture, which is over 10 years dead.
That can be quit a job, special when more usb devices are involved.
I don’t think it’s a good idea to move to an external drive. But if someone wants it…
And about the edits, in preferences you can set read from dop file and write to dop file.
Again, I’m on Windows.
Indeed, I’ve never seen PhotoLab’s database nested in the “Application Support” folder.
Hmm, strange, I’ll have to check that. It’s well possible though - I use PL as a plugin to Lightroom Classic and need neither PL’s history and projects and therefore didn’t check carefully enough.
Good luck for your asset management project. Getting metadata out of PhotoLab might not be trivial if you want more than the basics.
Photo Mechanic is highly valued by many users here, but it’s gone subscription, which might not be your cup of tea. Adobe Bridge and Lightroom can be used for “free”, meaning an account registration with Adobe, possibly another nogo.
Imagine buying a Ford from the Ford dealer, driving it off the forecourt and it breaks down. And as the owner, you get out your tool box and start trying to fix it, instead of taking it back to the dealer.
I admire people’s ability and ingenuity but the question you need to ask yourself is, “What did you pay for?”
It’s like you paying me to come round and mow my lawn.
Arguably yes. Their presence indicates one of two things
The database is currently in use, typically by PhotoLab, but also by any software you might be using to monitor the contents of the database or run an SQL script!
or
They indicate that the last run of PhotoLab ended in an abnormal termination.
Please check that PhotoLab is not running before you remove them, and/or that a program you were using to “peek” into the database isn’t still running.
Arguably if no program is still running then the files could be removed but equally they could be left (an copied with the database if you are backing it up) because the ‘write ahead log’ might contain something useful!?
@KeithRJ You beat me to the “punch”. But I would add to your statement " will be deleted when PL closes successfully".
Edit: The AI response to a question about SQLite adjunct files was
AI Overview:-
SQLite uses adjunct files (also known as temporary or journal files) to ensure atomic transactions (ACID properties), manage concurrency, handle crash recovery, and perform operations like sorting and vacuuming. The primary database content is stored in a single main database file, but these accompanying files are crucial for data integrity and performance.
The main types of adjunct files and their functions are:
Rollback Journals (-journal files): These files are used in the default journaling mode to implement atomic commits and rollbacks. Before modifying the main database, SQLite writes the original data to the journal file. If a crash occurs during the transaction, the journal is used to restore the database to its original state, preventing corruption.
Write-Ahead Log (WAL) Files (-wal files): In WAL mode, this file serves a similar purpose to the rollback journal but improves concurrency by allowing readers to access the database while a writer is active. Changes are initially written to the WAL file and later moved to the main database file in a process called a checkpoint.
Shared-Memory Files (-shm files): These files are used when SQLite is in WAL mode to provide a block of shared memory that helps multiple processes coordinate access to the WAL file.
Super-Journal Files: Used for transactions that modify multiple attached databases simultaneously, ensuring the changes across all affected databases are atomic (all commit or all roll back together).
Statement Journals: These temporary files manage the rollback of partial results of a single, multi-row SQL statement if a constraint violation or other error occurs within the statement.
Temporary Databases/Indices: SQLite creates internal temporary files (which may or may not touch the disk, depending on configuration) for various operations, such as materializing subqueries, sorting results for ORDER BY or GROUP BY clauses, or running the VACUUM command.
These files are typically created and deleted automatically by the SQLite engine as needed and manage essential background processes to maintain the database’s reliability and performance.