In PL9 the batch-rename in conjunction with a move is leaving behind the sidecars. It doesn’t always happen and I’m working to narrow the circumstances, but it appears to be as follows:
Select some files (3 or 4) and apply a correction (doesn’t really matter what)
Batch rename them.
Move them to another folder (in the app, not in the OS)
In some circumstances, the .dop files are not moved, and they are orphaned in their original folder. In a couple of instances, sidecars for some of the selected files were moved and some were not.
Since this is a PL9 issue I’m not sure how important it is, and I will wait until I install PL-10 to see if it’s still occurring.
Do you find that leftovers are more frequent iy fou act more quickly?
PL does a few things asynchronously and maybe there is a problem in handling the sequence in the correct order. Never mind if caused by the app or the OS.
BEWARE:
macOS 15.8 has issues with Finder/Quick Look/RAW support.
→ Stick to the OS you have.
While making order with old photos, selected about 1700 images in the browser and then moved them to parent folder, using “drag onto” in PL10.0.1/Win. It took about 5 seconds to complete and worked as expected (as seen so far). But completing “remove missing folders” took over 20 minutes for some 20 folders with about 50,000 images missing, iirc. So, maybe batch renaming is slow and you have to wait a bit. On the other hand, it shouldn’t be that slow for 3-4 files. Could be some bug.
If you edit image, the DOP file is updated asynchronously, sometimes with large delay (20 sec?), but that’s a different case, which shouldn’t happen with batch renaming, imho. EDIT: Maybe you made some edits just before moving images?
Personally I’ve used batch renaming only in exports for the public, putting timestamps in filenames to get alphabetical sorting same as sorting by shot date, when using 2 cameras (with synchronized time before each session) – something like {Year(YY)}{Month(MM)}{Day(DD)}{Hours(24h)}{Minutes}{Seconds}_{Original name}. In PL browser I use sorting by Shot Date, so I don’t have to rename the files for this purpose.
Could very well be a key to the issue. I will keep an eye on that.
If no one else has reported this by now in the mature PL-9, which has been out for a year now, I would suspect something behavioral on my end. Thanks for the insight.
If HOW you do things causes some sidecars to NOT move, the problem is not with you, but with the software still. If the commands were properly queued and executed, no sidecar should be left behind.
Q: when you find leftover sidecars, do they contain the edit you did before renaming?
(knowing this could help DxO find the issue, if you contact DxO support)
I can reproduce the issue, testing with 60 test images, all on the local drive, in a separate volume on a 2019 5k iMac and macOS 15.8
This is what I did in a fluid (but not too hasty) sequence.
make sure that PL automatically exports and imports sidecars
select all images
apply B&W preset to all images
rename all images (app suffix “-1”)
move to a different folder
quit PL
Found
2 LEFTOVER SIDECARS
60 IMAGE and 59 SIDECAR FILES in the new location
that all files were renamed though
So, this is what seems to happen: PL moves files by copying them to the new place before deleting them in the old place. If the move is disturbed (by e.g. quitting PL), some pending actions are lost/aborted/whatever.
@RexBlock Feel free to copy the above text into your support request.
When you edit an image, PL keeps the edits in memory until you move on to the next file. This makes sense because you don’t want file I/O for every little edit.
If multiple images are selected, the edits for all images are held in memory and not flushed until you deselect them by moving on to another image. If you leave the selection in place, and move the selected images to another folder, then the .dop files start getting left behind.
It isn’t predictable and in some cases it didn’t happen, but I can pretty reliably make it happen with 4 or 5 images selected. Evidently PL performs the move asynchronously with the I/O flush and it’s random chance which sidecars are moved, which are not, and which are lost.
So, it’s off to make a support request. Thanks everyone for bearing with me on this.