Normal behaviour when overwriting dopfiles?

Ive encounter a strange thing.
i replaced my folder i worked on with explorer including dopfiles a wile ago.
(i use a importfolder for new images i need to proces to keep track and when i am done i transport the hole folder to my raw file archive.)
i also did a extra folder inside that folder to backup dopfiles.
(because i can’t “lock” individual dopfile to prevent changes i just copy and save those all in a extra subfolder.)

So i opened dxo plv1.2 and selected that folder in my archive expecting to see my adjustments on those images again. Somehow i didn’t see any other then “default” preset.
as i am playing in library for EA v2.x and even when i have auto write to dop “off” it could be messing with my DB of v1.2 . (suppose it shouldn’t because it has two different DB’s)
anyhow, i copy paste my backed up dop files over the others and reopend DPL (quick and dirty solution :wink:)

  • i got my settings/adjustments back in filename 1 jeejh:+1:t3:
  • and a virtual copy (2) who where default preset. (the former look):open_mouth:
    Is this a DB vs Dopfile inconstistency? so it’s creating a virtual copy because it is seeing different data in the DOP-file then in it’s DB?

edit: to be sure i am not seeing things i did a second folder.
indeed all where" default preset" dop files - dated this day.
again a copy paste and again virtual copies emerge.
thus it is consistant.
strange that my backup paste in explorer causes a virtual copy in dpl and the former “original” becomes a “number two” when i restart DPL.

I’'m not sure I understand exactly what you did but I created a new folder with Windows Explorer and copied an existing folder with images and .dop adjustment files to it. I use FL 2.1 on a fully updated Windows 10 machine. When I open the new folder in Photolab all my adjustments were still there. If this differs from what you did, please let me know and I will attempt to redo it.


i replace/move a folder, which i developed in a “importfolder” with DxO v1.2, from the import folder to and other folderstructure as in “my archive”
note 1 i use v1.2 not v2.x (didn’t update, :shushing_face:)
note 2 i think i don’t have a “refresh DB” actionbutton in v1.2

ok i wil do some editing on a folder and then move it with dop files to my archive to see what’s happens.
step 1 open folder in dplv1.2 located in importfolder.
step 2 create dopfiles and DB entries by editing those rwfiles.
step 3 export jpegs
step 4 create “backup dopfile” folder inside explorer. (copy paste dopfiles in there.)
step 5 close DPL and move folder in to archive.(can’t inside dpl)
step 6 open dpl and go to new location reopen that folder.
see if its opening as default preset.

hmm i think i go bonkus,
now its ok.
Can it be when i rename folder too?
(i suspected that rawfile and dopfile are twins and that the DB and DOP data importancy is first dop then DB info. so moving around, renaming files is ok aslong as dopfile and rawfile has the same name.)

When you say you used Explorer to create and move folders did you run Explorer from within PhotoLab? I just did that and got somewhat different but equally strange results. To correct the issue I exited PhotoLab, and when I restarted it all was well. I suspect my issue was related to the database which I’m guessing was temporarily confused by using Explorer within PhotoLab to move things around while the database was still open. If Photolab was closed when you used Explorer to move things around and rename them, than I have no clue what might have caused the issue you saw.


No i not tend to do that.( but maybe i did few days ago) most of the time i clear my import folder when i did a test view on my TV. if it’s ok i transport jpegs out the exportfolder into my database for PSE13 (the tagging naming and such) Then i transport/move the rawfile folder after making a subfolder for backup dops in to my raw archive. (sometimes renaming folder as “date garden” or date daytrip to…) easier to find again.

i gues my issue was also a Database which was confused, (i remember i copied the rawfile’s in my test folder for v2.x. to test some things, but they have a different DB so that can’t be the thing.)
(maybe i accedently deleted the dopfiles for sake of preventing version mix up thinking i stil have the backup and forget to actual replace the new made one’s with the backup one’s. :thinking:

(i wil keep a eye on this matter see if i can reproduce the issue)

stil the matter of when copy and overwrite the dop-files it produces a virtualcopy.
And the original one becomes the virtual 2 and my pasted dop-file becomes the 1 (original).
I am actual pleased with this, because when i do this i don’t care manual deleting leftovers.
now i can check first before i delete the virtual copy.

Sorry I’ve been unable to help you. You seem to have a fairly complicated process flow using a few different tools. Perhaps you accidentally did something differently than you normally do.


no problem,
my work flow is quite straight forward, but because i do some testing in AE dxo pl v2.1. i have some side roads build in.

normal work flow:
1 import by photofunstudio of panasonic in a importfolder.
2 culling
3 opening DPL. editing and selecting.
4 export to my exportfolder.
5 watching on FHD tv for errors.
6 moving folder to fotoarchive and rawfiles and dopfiles to raw archive.
7 tagging and naming in PSE DAM

But i think it’s a bit of action by use of my testing in EA v2.

this is a long known problem and DxO doesn’t consider this a bug but a feature (they don’t want us to lose settings). You will find postings from me describing the details.

As far as I remember, the virtual copies are created only if you restore dop files on a local drive, not on a removable or network drive.

I repeatedly asked for more control over this behaviour because I often copy files to a faster PC, process them there and copy the dop files and jpegs back.

Therefore I have to delete the DxO database before every restore.

Please file a change request if you agree with me that we need more control over this. DxO might ask the user whether to overwrite, and/or there should be a general setting for the default behaviour.


And this is true. But I’ve got good news - we are working over some changes of this behavior.

Svetlana G.

1 Like