PL7.18, PL8.8 and PL9.0.2 DO NOT synchronise with any external Directory modifications

BHAYT · September 28, 2025, 11:09am

A number of posts recently have once again raised the issue of whether PhotoLab can automatically resolve issues caused by making external changes to directory naming, moving directories etc.

The answer is that is an emphatic NO it cannot/does not and according to my simple test couldn’t in PL7.18 so nothing has changed for the better or worse.

The test is as simple as can be

One directory with an image
Assign a Keyword to the image, e.g. “Move-Test” or “Move-Test” i.e. my typo!!
Search for “Move-Test” (“Move-Test#”!), there should be just one of them found
Ensure that the directory is selected and change the name of the directory externally.
It will appear as if PhotoLab has spotted the change automatically but
Repeat the search test and you will get 2 images found

The reason is simple, PhotoLab didn’t actually notice that the name has been changed, it “just” discovered a new directory and imported its contents.

So the fact that DxPL is actually “watching” the directory makes no difference whatsoever, DxPL simply treats it as a “normal” new directory discovery.

So that there are now two entries in the database, in this case, one related to the old name and one related to the new name.

This problem can affect searches and ‘Projects’ and make a nonsense of both.

Such “?” entries typically provide a ‘Fix Path’ option to allow the damage to be “repaired” and that is the only way to re-align the database with reality.

However, PhotoLab’ Indexing '(re-indexing) is driven not by what is in the database but what is on disk, so “orphaned” entries will simply remain in the database.

Any ‘Project’ entries pointing to images in a renamed or moved directory will suffer the same problem.

But ‘Projects’ might be part of the cause of the “lack of interest” by DxO in fixing the problem!?

If a ‘Project’ is “damaged” by external changes, which may affect only some of the entries in the project, those can be “fixed” by using the ‘Fix Image Path’.

This could be a tedious exercise depending on how may external changes have been made but at least remedial action is possible.

However, depending on how well the database clean-up is coded it is possible that the clean-up could leave ‘Projects’ with “hanging entries” or they are removed leaving the ‘Project’ very different than it was originally.

I don’t believe a proper clean-up is actually that difficult to write but I don’t know enough about the internal working of PhotoLab to be sure of that statement.

The tests step by step snapshots for the PL8.8 test

BHAYT · September 28, 2025, 11:21am

The Solution is not to do any directory (or file re-naming operations outside DxPL)!?

But there is no 'Move Directory (Folder) operation available so that ultimately limits the options available to prevent this sort of database “corruption”.

Plus the advanced renaming operations available in a variety of packages are simply not available in DxPL!!

HGF · September 28, 2025, 12:34pm

DxO is brilliant in raw processing but very poor in File Management. Metadata, Keywords, Rankings, Flags, groupings, versioning, all of these I’m doing in Imatch. This works perfectly.

BHAYT · September 28, 2025, 12:44pm

I also own a copy of IMatch and that may well provide metadata handling and integrate well with DxPL but that can’t fix the File management issues of DxPL.

Only DxO can provide the infrastructure to manage File management and keep their database in Sync. To be honest if you do not use DxPL searching or maintain ‘Projects’ then the database drifting out of sync doesn’t really present any real problem.

Either ignore the problem or do what some users do and delete the database before starting a new editing session.

Personally I consider the current omissions to be amateurish at best and reprehensible at worst and relatively easy to fix if only they could be …!?

HGF · September 28, 2025, 12:59pm

I agree . Let see what dev will do.

John7 · September 28, 2025, 1:06pm

They have had years but as been said many times chosen to ignore the need

Wlodek · September 28, 2025, 1:27pm

This is unsafe with any software. NEVER edit externally any element of the current directory path. I would treat it as a user error.

There is a Rename option, also for the directories, but more general cut/copy and paste operations on directories would be welcomed.

Now, how about ‘Move’ operation on selected group of thumbnails.
If the selection contains some, but not all virtual copies, what action would you like PL to perform?

platypus · September 28, 2025, 1:47pm

Agreed, but other apps can help to fix these errors. The lack of such functionality in PhotoLab effectively disqualifies PL as an asset manager for me.

BHAYT · September 28, 2025, 3:17pm

@Wlodek I was testing, not doing this for “real”. I deliberately did it this because others have reported that external renaming works.

But it can’t, it just hasn’t been programmed with the necessary “smarts”.

By choosing the very directory that I am renaming I am giving DxPL the very best chance of being able to keep things in sync, i.e. if it is ever going to work it should under those circumstances!

Plus if you look at the result after the rename it looks as if DxPL has actually got it right!

Previously I have used ‘Projects’ to show that DxPL hasn’t realised what is going on, this time I used keywords as being an even easier way of showing what I wanted to show, i.e. that DxPL is as dumb as a dumb thing on a dumb day that is dumb, even when things are happening under its very nose.

Even worse DxPL will be using the same operating system hooks that Folder Monitor and my programs use to watch for activity in the Directory, principally for xmp sidecar changes or jpg metadata changes etc…

But it chose to ignore what is would have been told about directory changes and just discovered the new directory, how excruciatingly dumb is that!?

And if I remember correctly DxPL actually understands that and fixes up the database in line with the renaming operation, hooray! But I was looking at the issue that a lot of users encounter when they are using software with a lot more data management “smarts” than DxPL alongside DxPL.

Yes but what about a Copy operation, on everything, including images. “Drag and Drop” is just that, an inconvenient “drag” at times.

Currently Dragging the Master drags all the VCs as well, dragging a VC takes the Master and all the VC s(just tested it on PL902).

If only selected VCs are required then it should be possible to select them and drag & drop them (or the newly implemented Copy/Cut paste) and the [M]aster (and image etc…) must come along for the ride, would be acceptable.

The better option is to take the selected VCs and the original image and xmp sidecar file and promote the first VC in the copy list to become the [M]aster.

Then completely destroy the artificial [M]aster and VC approach and create Copies which can be re-ordered and deleted at will including the “precious” [M]aster, then I can just write C1, C2 …C1000 and drag and drop any Copy to any position in the hierarchy or cut any copy and paste it anywhere, even to another directory!

@platypus Agreed.