PL4 creates .dop sidecars for renamed exports

While working on a new set of RAW files with PhotoLab 4: after exporting a number of them individually to TIFF and JPEG, I realized that PL4 was still using the export settings I had used for PhotoLab 3. I wanted to change the filenames of these exported files. So while PL4 was still open and running, I opened a file manager (Unreal Commander) and started renaming those exported TIFF and JPEG files. As I did so, PhotoLab created .dop sidecars for each of the JPEGs and some of the TIFFs. When I deleted the sidecars, they reappeared.

I haven’t seen this behavior before. It’s not unusual for me to do file operations like this in a folder that PhotoLab still has open. Do I have to do all my renaming within PhotoLab now?

As expected, when I deleted all the exported files using PhotoLab (still in the Customize tab), the sidecars were also deleted.

Have you tried renaming the files with DPL closed - this should solve the problem

You’ve gotta be a bit careful about renaming images “in a folder that PL currently has open”, Greg. This is so for two main reasons;

  1. Any changes to image names must also include the same change being made to its associated sidecar/.dop file (assuming you’re using sidecars?) at exactly the same time (within millisecs !) - - and;

  2. If PL is running at the same time as you’re making these changes then (because PL is continually monitoring for “new” images in the current folder) PL might detect a newly renamed image before its associated sidecar file is renamed - - so that it sees it as a new image with NO related sidecar … and it then creates a new matching sidecar, but without any of your corrections (now “orphaned” in the old sidecar file).

This problem is particularly likely when renaming multiple {images+sidecar} files at the same time, 'cos;

  1. This makes it more likely for there to be a delay in time between the image being renamed and its sidecar being renamed - and, therefore, more time for PL to detect a “new” image without an associated sidecar/.dop file.

  2. Some file managers (such as File Explorer) do not necessarily apply renames, at the file-system level, in the order in which you requested them - - eg. they might be applied in the order in which they physically reside on disk - - such that, say, the actual rename for a sidecar is applied well after the image rename, by which time PL has already detected a “new” image … with implications as detailed above.

I have no experience with Unreal Commander - but this may explain your observations.

HTH - John M

1 Like

Thanks, John - I realize that. The files I was renaming had no sidecars. They were freshly-exported JPEGs and TIFFs. PhotoLab added the sidecars after I renamed the files. My defaults for RGB files is “No Corrections” - so I am at a loss to explain the sidecars.

1 Like

Mmm - OK, that is puzzling then.
Just to be certain; you’re quite sure that PL had not been “pointed at” your export destination folder ?

This, in and of itself, does not mean that a sidecar/.dop will not be not created - The action of exporting an image will result in a creation of a sidecar/.dop (assuming you have sidecars enabled - in Preferences).

John

Yes, John, the exported images are in the same folder as the source images. But I don’t think you are understanding the problem I’m experiencing. Let me explain this another way:

I work on a .ORF RAW file. PhotoLab creates a .dop sidecar file as I make edits - as it should. When I’m done with my edits, I export the final image to two files: a watermarked .JPG and a .TIF for which watermarking has been bypassed. These files are written to the same folder as the .ORF file. No sidecars exist for the .JPG and .TIF files, and I never select these files using the PhotoLab image browser. At some point, I decide to change the suffix in the names of the .JPG and .TIF files. I do that outside of PhotoLab. PhotoLab sees the change and updates its image browser, but for some reason also creates .dop sidecar files for the renamed .JPG and .TIF files. Files that it has never opened for viewing or editing. My question is, why is PhotoLab doing this?

OK - Gotcha. I emulated your example, Greg, but couldn’t get PL to behave as you describe.

A simple solution would be to direct your exports to a sub-folder, beneath your RAWs … if that would work for you (?)

John

Thanks for trying, John! Fortunately, it’s moot for me now that I have set the export parameters the way I like.

1 Like

I fear, Greg, that I’m probably about to do the equivalent of “teaching Granny to suck eggs”(!) - - but, for other readers, at least;

It’s easy to direct your Exports to a custom folder beneath the folder containing one’s RAWs;
image In fact, the '.\ ’ prefix is not actually needed.

John

1 Like

:laughing: It’s good advice, John! You’re going to have to put up with my stubborn side, though. Going through my lengthy log files, I can see that PhotoLab detects the renamed files using its database. It sees them as “renamed” and then “changed” (for some reason - probably the folder and file timestamps, probably not EXIF) and creates a sidecar for each. For example, from my DxO.PhotoLab0.txt log file:

2020-10-22 22:24:11.648 | DxO.PhotoLab - 119080 - 202 | Threading - Info | Releasing thread from controller #25
2020-10-22 22:24:11.648 | DxO.PhotoLab - 119080 - 202 | Threading - Info | Thread controller #25 is empty
2020-10-22 22:24:50.305 | DxO.PhotoLab - 119080 - 1 | Threading - Info | Adding thread #1 to controller #25
2020-10-22 22:24:50.305 | DxO.PhotoLab - 119080 - 168 | DataModels - Trace | DopDirectoryListWatcher => Type:Renamed / Folder:False / Name:17310843_PL4wm-97_1.jpg / FullPath: C:\Users…\17310843_PL4wm-97_1.jpg
2020-10-22 22:24:50.305 | DxO.PhotoLab - 119080 - 168 | DataModels - Trace | DopDirectoryListWatcher => Type:Changed / Folder:False / Name:2020 Niagara Falls St Pk / FullPath: C:\Users…
2020-10-22 22:24:50.305 | DxO.PhotoLab - 119080 - 1 | Threading - Info | Adding thread #1 to controller #13
2020-10-22 22:24:50.510 | DxO.PhotoLab - 119080 - 139 | Threading - Info | Releasing thread from controller #13
2020-10-22 22:24:50.510 | DxO.PhotoLab - 119080 - 139 | Threading - Info | Thread controller #13 is empty
2020-10-22 22:24:50.543 | DxO.PhotoLab - 119080 - 168 | Threading - Info | Releasing thread from controller #25
2020-10-22 22:24:50.543 | DxO.PhotoLab - 119080 - 168 | Threading - Info | Thread controller #25 is empty

(snip)

  • Modified Entity : Sources [Id = 548]
    • Name : “17310843_PL3j97_1.jpg” -> “17310843_PL4wm-97_1.jpg”
    • NormalizedName : “17310843_pl3j97_1.jpg” -> “17310843_pl4wm-97_1.jpg”
  • Modified Entity : Items [Id = 637]
    • Name : “17310843_PL3j97_1.jpg” -> “17310843_PL4wm-97_1.jpg”
  • Modified Entity : Sources [Id = 549]
    • Name : “17310843_PL3t16_1.tif” -> “17310843_PL4_1.tif”
    • NormalizedName : “17310843_pl3t16_1.tif” -> “17310843_pl4_1.tif”
  • Modified Entity : Items [Id = 639]
    • Name : “17310843_PL3t16_1.tif” -> “17310843_PL4_1.tif”
      2020-10-22 22:25:10.362 | DxO.PhotoLab - 119080 - 139 | Database - Info | Profiling DxO.OpticsPro.Database.DOPDB.SaveChanges : 7 ms
      2020-10-22 22:25:11.417 | DxO.PhotoLab - 119080 - 1 | Threading - Info | Adding thread #1 to controller #25
      2020-10-22 22:25:11.417 | DxO.PhotoLab - 119080 - 202 | DataModels - Trace | DopDirectoryListWatcher => Type:Created / Folder:False / Name:17310843_PL4wm-97_1.jpg.dop / FullPath: …

:face_with_raised_eyebrow: Neither Unreal Commander nor Windows Explorer update the file timestamp on rename. However, the folder timestamp is updated by U.C. So I think I found the cause.

1 Like