Hi,
I am reorganising my image library by changing its folder structure. During this process I have noticed a number of .dop files with names similar to this tmp.{17AC4578-B525-8e4a-8846-2AACD2FBF2AB}.jpg.DOP
I guess that the long hex string refers to a file but it does not appear to be UUencoded.
I have two questions:
best wishes
Simon
No and no…but let’s look into it a little bit closer.
If you delete the .dop sidecar file(s), you’ll lose all edits, keywords etc. depending on how “sane” your PhotoLab database is. Now, if you change your folder structure while PhotoLab is off, it’s database will not represent the new structure, but the old one…and you lose your edits, keywords etc., unless your .dop sidecars are present and have the same name as the image files they belong to.
From your post, I take that the mess has already been created and therefore, I’d try to match all available .dop files to their respective image file. If things are well, you should see pairs of files like so:
QUIT PHOTOLAB NOW! READ ALL BEFORE ACTING!
If the name of the .dop file does not match the pattern above, I’d look into the file in order to find out, to which file the sidecar originally belonged to. The respective file name can be found in the sidecar. Look for “Name”
Sidecar = {
Date = "2024-10-18T07:36:46.7180000Z",
Software = "DxO PhotoLab 8.1.0.35",
Source = {
CafID = "C803b",
Items = {
{
Albums = "",
CreationDate = "2024-10-18T07:36:16.3770000Z",
IPTC = {
},
Keywords = {
{
"Rose",
},
},
ModificationDate = "2024-10-18T07:36:39.9660000Z",
Name = "20071103_1571_R.cr2",
Orientation = 1,
OutputItems = {
},
ProcessingStatus = 1,
Rating = 0,
You can now rename the sidecar in order to create a matching pair as shown above.
Now, we have the potential issue of the UUIDs (creating virtual copies)
VignettingActive = true,
VignettingIntensity = 100,
WhiteBalanceRawActive = true,
},
Version = "19.0",
},
ShotDate = "2007-11-03T12:32:50.0000000",
ShouldProcess = 2,
Uuid = "29977F9E-8771-4C46-A8C6-F4EC54F80860",
},
},
Uuid = "EC4DE6DA-8E71-4A11-B11A-42A8CAA1255D",
},
Version = "19.0",
}
To prevent a proliferation of VCs, rename your DPL database, then start DPL and have it index your reorganised structure.
CAVEAT: I’m on Mac and your mileage might vary on Windows. Sidecar text taken from files as displayed by BBEdit (Mac only) but any text editor should be able to display a .dop file, it might look less structured though. Also, there is no guarantee that nothing is lost. Depending on how many unmatched pairs of fies you find, it might be best to restore the original structure and start from scratch. Whatever your situation is, it’s hard to evaluate and give more hints than above, we simply don’t have enough info about your platform, number of files, screenshots etc. Until then, I’d hold off reorganising to prevent more issues.
I have seen these files before and I think they are created due to a PL crash. I found that I had my image file and. dop files for all my files, so I simple deleted these strange .dop files and all was fine.
Thanks for both your replies. I followed the advice given by platyus and tracked down a few of the orginal image files. my case mirrors KeithRJ’s experience in that in the ones that I have checked the original file has an associated .dop file. In some cases the tmp.dop file refers to the original file name as set by the camera. In my workflow I append a the date time before the original name so it seems that the tmp.dop file has been created during the image file import process which is normally conducted by PhotoMechanic.
The tmp.dop files could have been created due to a crash or some other confusion caused by perhaps adding files to a folder that is being watched by PL. I shall check a few more and then probably delete them.
Best wishes
I don’t expect that to be the cause … I do this all the time (purposefully), and PL handles it without problem.
John