PL4 picking up old file name from .dop file

[platypus (Canon & Mac (Intel and M1))]

@John-M

When a pair of {image+sidecar} files are renamed from outside PL, there is no need to update the filename within the sidecar file … PL does an auto-repair the next time it encounters this combo.

DPL4 on Mac does NOT fix the name or anything else in this case.

I’ve changed the names in Finder while DPL was running and I noticed that DPL flashes the new name for a split second and then returns to the original name or the one stored in the .dop file. Just for fun, I changed the name in the .dop file too and reimported the sidecar. Nevertheless, the name displayed is still the name when the file was opened for the first time. Changing the name (and .dop content) while DPL is off does not do any good either.

The database seems to be “stronger” than the sidecar or in fact a user action (import sidecar) in this case. In my opinion, a user action should override the database, which is what happens in DPL when I change exposure, WB etc. Renaming a file seems to be excluded though.
One small (missing) piece of the DAM puzzle

[Joanna (Joanna Carter)]

@platypus

The database seems to be “stronger” than the sidecar or in fact a user action (import sidecar) in this case. In my opinion, a user action should override the database, which is what happens in DPL when I change exposure, WB etc. Renaming a file seems to be excluded though.
One small (missing) piece of the DAM puzzle

Indeed. Which is why, in the course of my investigation, I delete both the database and the cache after editing the .dop files - something that is not an option for those who make use of either projects or keywords.

[Pathal (Patrick)]

@Joanna

What I have found is that, despite deleting both the database and cache, I still can’t get rid of the “ghost” file name unless I manually edit the .dop file. PL doesn’t seem to know how to fix it, at least on the Mac version

I confirm this on Mac version.

While the image file and dop file in the finder are well renamed, the name of the file inside the dop is obviously unchanged, and by copying them into a new folder, DPL put the previous name in the thumbnail image, but the pop-up with information on the image is showing the new name.

[Joanna (Joanna Carter)]

At the moment there is one “internal” name for each version in a .dop file, which is, sort of, ignored or used depending on circumstances.

How about if DxO were to formalise having the two different names available into:

• having the physical name from the actual file for the title bar of the main window and the file info
• having a name for each version stored in the relevant virtual copy in the .dop file which would be displayed on the relevant thumbnail?

[John-M (Melbourne, Australia - Win10)]

@Ralf_Brinkmann

I don’t know exactely how IrfanView works. I just open the image file, press F2 and change the name. IrfanView changes the name of the image file and the *.dop file at the same time. And I even can do that while PL is open.

Yes, this works fine with the Windows version of PhotoLab (and PL happily updates the filename stored within the sidecar/.dop file) - but, as reported by Joanna, and others, it does not seem to work with the Mac version.

On the Win environment, this ability to rename {image+sidecar} pairs, from outside PL, is an extremely valuable feature - which I use just about every time I use PhotoLab.

John M

[Joanna (Joanna Carter)]

@John-M

Actually, Ralf, there’s no need at all to rename the filename within the sidecar/.dop file … This internal name doesn’t seem to be used at all (at least, not for anything important/critical), and PL will update it the next time it encounters this {image+sidecar} duo.

This might be the case with the Windows version but with the Mac version, the name in the .dop file is used for display on both the title bar of the window and for the thumbnails

[platypus (Canon & Mac (Intel and M1))]

@Joanna

with the Mac version, the name in the .dop file is used for display on both the title bar of the window and for the thumbnails

…not sure about that. I edited the name in the .dop file and nothing changed on title bar and thumbnail…

Moreover, while I was fooling around with my tests, DPL started to create virtual copies. I therefore decided to delete database, cache and .plist files to make a clean slate.

[Joanna (Joanna Carter)]

@platypus

…not sure about that. I edited the name in the .dop file and nothing changed on title bar and thumbnail…

Yes, I would expect to have to delete the database and cache to get the change to be picked up but, even then, it still seems pretty unpredictable.

@platypus

Moreover, while I was fooling around with my tests, DPL started to create virtual copies. I therefore decided to delete database, cache and .plist files to make a clean slate.

I had that happen but couldn’t reproduce it to order. Which .plist files are you deleting?

[platypus (Canon & Mac (Intel and M1))]

I deleted the .plist files in my preferences folder. The ones for DPL and those for DPL’s workspace settings. Deleting all these files means that I had to redo settings and workplace to my taste.

[Olivier]

Hi,

As @John-M noted, I encountered the same problème. He has put a link on the corresponding thread in it’s post.

Since using PhotoLab (version 1), I have always used Lightroom to manage images and therefore rename them. I have never had this problem before. But I can’t say for sure if these images were renamed with Lightroom as I also tested PhotoLab 4’s batch rename feature.

As mentionned by @Joanna, during my tests, I started to see some weird things with virtual copies created on their own … So I deleted the databases and config files to restart from scratch. Everything is back to normal regarding the virtual copies (except that the master images and the virtual copies seem to be inverted) but the problem of images names is still present.

Olivier.

[platypus (Canon & Mac (Intel and M1))]

@Olivier

As mentionned by @Joanna, during my tests, I started to see some weird things with virtual copies created on their own … So I deleted the databases and config files to restart from scratch. Everything is back to normal

Same here… I usually start and quit DPL a few times before actually using it. Changes can take a second launch before taking effect.

[be51 (Escaich)]

I never rename pictures within PL because I want to rename all files with same identifiers (ig .ARW, .JPG, .ARW.dop, .json) *.
Does PL do that ?

I always use identifier from camera, with two adaptations : change prefix to a custom one in camera (A7R for me), rename tens of thousands.

Cameras give a sequence number, typically DSC00001 to DSC09999 and renumber from 0.
I use macOS to rename last import from DSC0 to DSC3 if I hav shot more than 30000 pictures.
It renames raw and jpeg.

• when I say “I rename”, I speak about insertion of an explicit short description, ie “DSC45874 Sunset in Corsica”.

[Joanna (Joanna Carter)]

@be51

I never rename pictures within PL because I want to rename all files with same identifiers (ig .ARW, .JPG, .ARW.dop, .json) *.
Does PL do that ?

Batch rename doesn’t propose changing the extension; renaming a single file does (@StevenL does this need looking at as an anomaly between the two?

@be51

I always use identifier from camera, with two adaptations : change prefix to a custom one in camera (A7R for me)

This sounds sensible. I also change the prefix in the camera.

@be51

… rename tens of thousands

Wow!!! Are you really shooting tens of thousands? I hope not in one session!

If you really are shooting so many, don’t forget that shutters have a life expectancy - my Nikon D810 is 200,000 actuations, then I might need to either get either the shutter or the whole camera replaced.

Also, please note something that has been said many times in these forums - PL was never intended to handle such large numbers of files.

Do you really need to take and keep so many pictures?

[be51 (Escaich)]

The length of numbering sequences is 9999, what is insufficient.
My previous camera is about 48000 pictures and actuel one about 38000.
The capacity is five digits, so I use the fifth digit and it is convenient.
If I have more than 99999, I will change a character !

[be51 (Escaich)]

I have recently got the same issue as Joanna, perfectly described.
I have also found in dop file the old name.
As I told above, I rename my files for the fifth digit.
The issue occurs for a few percent of the pictures of a same folder ; all have been renamed in finder

On this picture, you can see that file A7R35138 has been developed under name A7R05138.

As I couldn’t see it, I redeveloped it and I never got the message asking if I want to replace existing file or unique name.
I have always this message in normal process (>95% of the pictures).
So it is a double bug !

[John-M (Melbourne, Australia - Win10)]

This discussion makes me VERY nervous !

For the Win version of PhotoLab, the filename held within the sidecar/.dop file has no operational purpose … such that it’s possible to rename the sidecar/.dop file AND it’s associated source-image file from outside PL, (provided they are renamed identically) and PL will identify the related sidecar file and load it the next time the source-image is accessed.

a) Is this not how it works in the Mac version ??

b) For many users, like me, who regularly rename {image+sidecar file} pairs from outside PhotoLab, this flexibility and robustness is a key feature.

So, DxO, please no changes to this critical behaviour [for the Win version].

John M

Edit: Clarified my plea as referring to the Win version of PL.

[Joanna (Joanna Carter)]

@John-M

For the Win version of PhotoLab, the filename held within the sidecar/.dop file has no operational purpose

And this is where the situation seems to be different for Mac.

If you look very carefully at the screenshot of Finder in my initial post, you will see that the file names are from JNA_0020.NEF to JNA_0024.NEF, as are the .dop file names.

But, if you look at the names on the thumbnails, you will see that the names are: JNA_0304.NEF, JNA_0305.NEF, JNA_0311.NEF, JNA_0316.NEF, JNA_0023.NEF and JNA_0319.NEF. That despite the names that Finder shows.

You will notice that the virtual copy of JNA_0023.NEF is correctly (re)named to match the physical file name. This is because I had deleted the database and restarted PhotoLab after creating the virtual copy; so, obviously, PL is reading the name from the physical file for the virtual copy but it is reading it from the internal .dop name for the master. If I don’t do a database deletion after creating a virtual copy, PL continues to show the old file name on all thumbnails, despite the physical files having been renamed.

@John-M

So, DxO, please no changes to this critical behaviour.

I am certainly not advocating any change that would affect the Windows version if it doesn’t exhibit this fault; I just want the Mac version to behave properly.

[update]

I just repeated my test with PL4.1.1 and the problem still exists.

I copied the same small folder of files I used for the first test to a test location and renamed the files to ensure that the physical file names matched those in their .dop files, just as if they had not been externally renamed.

I then opened PL4.1.1 and, sure enough, everything appeared fine with the thumbnails showing the correct physical file names.

Then I closed PL4.1.1 and used Finder to rename the image files and their .dops.

Upon reopening PL4.1.1, the thumbnails for the virtual copies were correctly renamed but those for the master copies were still showing the original file name.

Notice that the thumbnail shows a different name on the virtual copies (the new name) to that on the master.

Since they are both derived from the same physical file, I have to declare this a bug that needs fixing for the Mac version.

If you create a virtual copy from a misnamed master, the thumbnail will show the name of the copy as the same as the master, even after closing and reopening PL4.1.1. It takes deleting the database to reveal the difference in names between the master and its virtual copies.

[update 2]

Just to prove what can be done if you edit the file name in the .dop file

@StevenL this seems to be totally reproducible. Can you look into it?

[Sigi]

I have run into the same problem on the Mac. I have had to rename some files in my DAM software.
The files were with their old names in DXO because I processed them previously.

• DXO did not recognize that I have changed the name, neither in “Photo Library” nor in “Customize”
  I expected question marks but I see the thumbnails with their old names
• In the “Filmstrip” I also see the thumbnails with their old names - I expect also here question marks
• When I edited these files - before the name change - I created a project and only here I see question marks. I then fixed the path of one of the files and this “worked” but not really. I see the thumbnail BUT the old name.

When I use “Rename” within DXO - on the file with the wrong thumbnail name - it fixes the dop file and the correct name appears.

This needs a fix urgently.

Sigi

[LCL]

I have had the same problem. With DxO closed, I renamed all the files of a set (image, xmp, dop) externally (a better finder rename). When I open DxO some of the files show the correct name. Some do not. All the files show the correct name in the info overlay box. Renaming the folder with DxO not running and reopening DxO and going to the newly named folder did not fix the file names. Manually editing the file name of the image in the corresponding .dop fixes it.

I’d say this is a quite bad bug even though the consequences are minor. It shows that the database is easily corrupted. Soon enough the consequences will be more severe.

[John-M (Melbourne, Australia - Win10)]

@LCL

With DxO closed, I renamed all the files of a set (image, xmp, dop) externally (a better finder rename). When I open DxO some of the files show the correct name. Some do not.
…
Manually editing the file name of the image in the corresponding .dop fixes it.

This is something that I do regularly, too - in the Win10 environment - as it causes no problem at all to the Win version of PL … it even repairs/updates the name in the .dop/sidecar file.

I understand that my response is not really relevant to this post - but I make it to emphasise that Win-PL’s handling of this situation is very effective and powerful.

John M