Reconnect sidecar after filename change

Hello Dears, I edited by RAW in dxo and then batch-changed the file name in a different program. This lost the connection between the RAW and the DOP file. Both files are still present in the same folder. I tried to rename the RAW back to the old name, but that just creates a new DOP file. How can I reconnect the renamed RAW file to the original DOP file, or import the edits from the DOP file, please ?

Change each ‘Name = “filename”,’ setting in the DOP file (for raws and jpg, if present) and rename the DOP file to match the RAW name. After starting PL and changing to that directory, PL should update its database automatically. I don’t know if using XMPs would require some extra actions. Tested on PL7/Win.

Edit: Some cameras include original filename in the raw file metadata, so you can use that in a batch (+exiftool), if your renamed filenames contain no clue about the original name.

I have gotten into the habit of only renaming files in DxO or outside DxO only before opening them in DxO for the first time. Renaming within DxO affects the RAW file and .dop and .xmp. In your situation, the only option is to rename the .dop and .xmp outside DxO.

Yes, I usually rename the raw files immediately after importing them, before opening them in PL. But well, things happen. Many thanks for the trick to rename the .dop file and edit the filename info inside the .dop file. In the present case, however, I may chose to edit the 20 photos again rather than spending time copy-pasting file names. I would have appreciated a solution like Image:Apply corrections:from a .dop file. Should I file a feature request for next time ?

@Wlodek I believe that changing the name in the DOP is unnecessary on Windows but that might not be true on the Mac version. DxPL(Win) updates the DOP with the new name when it writes it back to disk.

The original entries in the DxPL database will be “orphaned”.

As for the xmp sidecar, DxPL certainly doesn’t put the name in the basic xmp’s it creates but other software might!?

You are right. Sometimes ‘sicher ist sicher’ attitude is an overkill, but I couldn’t resist.

Do you know if PL cleans the “orphans” automatically, e.g. when (re)entering directory?


Entire directories can remain orphaned in the database, even more if you changed to another disk with the same structure but a different id (I have discussed that issue in other posts at excruciating length!!)

Hence, the recommendation that changing names etc. is done within DxPL whenever possible!

The lost space is not an issue (except an ever increasing database size) but external actions can lose ‘Projects’ pointers on Windows and ‘Projects’ pointers and 'Advanced History on the Mac (I believe) and create dead wood in the database on both systems.

1 Like

Thanks for pointing out possible problems with Projects (in my plans for the future).

Perhaps DxO should add ‘Database cleanup’ button, but that would be risky, because many users would not be patient enough, to wait for the process to finish. Still, I found PL to be quite tolerant to file/directory name changes, compared to some other software, since PL does some DB and cache updates on each directory change. Never had time/reason to work out the details and didn’t find a “trusted” explanation either, e.g. by DxO.

PL DB size depends also on how many Local Adjustments were made using a brush. Normal Settings take about 10KB, while LA brushing can make it hundreds of KB, all in DOP and PL DB. It’s not an issue for me but maybe for some it might be (?).

Unique disk IDs (e.g. scsi pages 0x80, 0x83) and GUID is a Microsoft and disk providers problem, that you can see also outside PL, especially in NAS environments. It was even much worse with older Windows versions, when Microsoft started to enter the server market, with clustering, multipathing, etc. It’s yet another (not-so)funny story about not having competent staff, just like much older Win NT vis OS2 story. But they are making progress…

@Wlodek this has been asked for many times by others and by me - very unlikely to happen. DxO even managed to cripple the indexing process going from PL6 to PL7 (on Windows) and turned it from a background process to a foreground process.

If the directory is “in scope” when the external change takes place then it is good at making the adjustments there and then. But changes made and discovered later are generally treated as “new” directories and the old entries are left to “rot”.

It is these changes that leave ‘Projects’ pointers “hanging”, DxPL follows the internal database pointers and attempts to locate the associated directory only to discover “nothing” and that results in this

In this situation the ‘Fix Image Path’ will appear for the “hanging” image pointers in a ‘Project’, i.e.

BUT only for ‘Projects’ and there are potential pitfalls to be found there as detailed later in the post!

DxPL is driven by traversing images on disk, adding them to the database or using the DOP found on disk to update the database (possibly with “Unwanted VCs”) but not via the database.

Hence, there is no way for it to discover that external renaming has occurred automatically except in the case of ‘Projects’ when pointers to disk images no longer work!

A reconciliation process needs to be driven by accessing image/directory entries in the database and attempting to locate them on disk and either abandoning the database entries (garbage collection) or offering the option to ‘Fix Image Path’ to the user.

When I first retested with the external renaming to (re)test the ‘Fix Image Path’ for this post DxPL doubled the number of VCs but trying to reproduce that issue today has so far failed, i.e. the tests have been well behaved thus far!

Until I remembered the scenario that causes the problem, please see the end of the post for details.

Agreed. I don’t do much LA so it doesn’t affect me much but could affect others greatly!

DxPL uses the id to prevent “confusion” with the drive letter (or so I believe), e.g. for handling external drives that may come and go, but the user then runs into trouble when a backup (or new) drive is substituted.

When I experienced the problem with digiKam it offered alternative courses of action but DxPL simply ignores the issue and assumes that the disk is to be treated as “new” and leaves the old database entries alone and adds the disk as new entries!

The current fix requires database “hacking”, which is particularly easy for NAS drives, but could easily be handled by DxPL itself! If possible the NAS issue can be avoided with DxPL by changing the mapped drive letter, providing that does not upset any other software!?

The problem with ‘Fix Image Path’ under certain circumstances:-

Using ‘Project’ pointers to locate database image entries that have become “detached” from the physical image entry works fine providing that the user has not already discovered the renamed directory by navigating in ‘PhotoLibrary’.

If the newly renamed directory is discovered by the user directly with DxPL the images in the renamed directory will be added to the database, so there are now the old “orphaned” entries with the name of the original directory and the new entries with the new name of the directory in the database.

Undertaking a ‘Fix Image Path’ to (re-)attach the images in the new directory to the ‘Project’ has real problems with “Unwanted VCs” as follows

The ‘Project’ with the “missing” images & the ‘Fix Image Path’ command:-

Locating the original images in the new location:-

The impact on the ‘Project’ - now pointing the additional VCs:-

The image directory complete with a lot on “Unwanted VCs” in this case:-

DxPL(Win) hasn’t fixed the path for the project in this case but rather it has added the original image data in the database to the “new” (renamed) image data in the database.

I feel that this is wrong and wonder what the original DxO rationale was for doing it this way!?

It certainly preserves the original data in the database that is for sure but it poses another problem because the ‘Project’ in my test case now points to the original entries but these are all VCs.

While it is easy to isolate and delete VCs, in this case that is all there is in the ‘Project’ so “fixing” the problem by deleting the additional VCs will empty the ‘Project’ hardly what I wanted to accomplish!