Greg,
Yes I agree with the point about not having PL open when you Restore - this way you’ll avoid PL possibly creating a DOP that doesn’t contain your changes that were in the deleted DOP. However, none of this material if you’re trying to recover VCs as PL’s changes to the DOP as you delete an image make any recovery impossible.
I’ll file a fault report.
@platypus Thanks for the update.
While not conclusive, i.e. because I was monitoring file activity not file contents and this is an annotated (by me) copy of the relevant section of the Log file.
So we have me making a change to force the DOP to be updated then copying the original DOP and then deleting the [M]aster in the test directory.
The outcome has already been documented, only the [M]aster data exists in the recovered DOP.
2024-11-14 14:22:17.024: F:\___Beta DXO PL5 - Tests Additional activated
2024-11-14 14:22:17.037: Saving settings to C:\Users\bhtho\AppData\Local\NodeSoft\FolderMonitor\FolderMonitor.xml
2024-11-14 14:23:18.593: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG modified
2024-11-14 14:23:18.661: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG modified
2024-11-14 14:23:42.622: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop deleted
2024-11-14 14:23:42.634: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
2024-11-14 14:23:42.649: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop created
2024-11-14 14:23:42.663: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop modified
2024-11-14 14:23:45.643: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
Copy & Paste of the existing DOP
2024-11-14 14:25:25.278: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG - Copy.dop created
2024-11-14 14:25:25.337: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG - Copy.dop modified
2024-11-14 14:25:25.337: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG - Copy.dop modified
2024-11-14 14:25:25.337: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
Deletion Test
2024-11-14 14:27:00.404: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop deleted <------DOP deleted
2024-11-14 14:27:00.500: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
2024-11-14 14:27:00.542: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop created <------DOP created & Modified
2024-11-14 14:27:00.597: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop modified
2024-11-14 14:27:00.597: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
2024-11-14 14:27:00.706: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG deleted <------Image deleted
2024-11-14 14:27:00.821: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
2024-11-14 14:27:00.948: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop deleted <------DOP deleted
2024-11-14 14:27:01.232: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
I’ve filed a fault report. I’ll keep you posted on the responses.
@SAFC01 Thank you and an update on locating copies, “Albums =” is the start of each copy and the “Should Process =” doesn’t quite end each copy.
“Albums” is not a field that is used by DxPL(Win) and tests on PL7 indicated that high jacking the field to use it to name things (via a text editor or programmatically) didn’t appear to cause DxPL any “stress”!?
For one [M]aster and two VCs we have
Sidecar = {
Date = "2024-11-14T14:23:42.6216130Z",
Software = "DxO PhotoLab 8.1",
Source = {
CafId = "C61005a",
Items = {
{
Albums = "",
CreationDate = "2024-11-14T14:10:13.1567278Z",
IPTC = {
}
,
Keywords = {
{
"[M]",
}
,
}
,
ModificationDate = "2024-11-14T14:23:42.6216130Z",
Name = "P1112346.JPG",
Version = "19.0",
}
,
ShotDate = "2024-02-12T13:19:10.9660000+00:00",
ShouldProcess = 0,
Uuid = "830C45A1-3665-4F0B-AFFA-B5F4B1745CB8",
}
,
{
Albums = "",
CreationDate = "2024-11-14T14:10:13.3769279Z",
Version = "19.0",
}
,
ShotDate = "2024-02-12T13:19:10.9660000+00:00",
ShouldProcess = 1,
Uuid = "7331C955-C282-4B4B-8715-2A648D779309",
}
,
{
Albums = "",
CreationDate = "2024-11-14T14:10:13.4139621Z",
IPTC = {
}
}
,
ShotDate = "2024-02-12T13:19:10.9660000+00:00",
ShouldProcess = 1,
Uuid = "AC996B02-FC5D-4410-814A-3E5CCDCC8050",
}
,
}
,
Uuid = "AE4D17E4-8D02-4207-B354-689F3B8DB5BA",
}
,
Version = "19.0",
}
Thank you everyone for checking. I’ve had no issues in the past, so not sure why it is happening now.
The issue does not occur in version 7.10.0 Build 287 (tested 5 files).
The issue occurs in version 8.1.0 build 434 and is repeatable (5 files, same results). Again, working from a Windows 11 PC, not Mac.
As a “workaround” the error does NOT occur when making the file restore when PL8.1 is CLOSED. The error occurs when PL8 is OPEN. I haven’t tested if the error occurs if I simply point PL8 to a different folder.
The virtual copy information has been removed from the DOP file for the properly functioning situations.
Folks who suggest that PL8 is attempting to build the dop files when the image is restored and then finds a dop conflict are likely correct.
My lesson learnt is to close PL when attempting to restore deleted items from the recycle bin. By extension, I should be structured to close PL, or change the active folder, whenever making file changes from the system’s File Manager (i.e. moving files outside of PL). This has been a topic before.
Perhaps there is a bug which DxO can fix, but for now I can live with the limitation to avoid PL - File Manager conflicts.
Again, Thank you!
@swmurray Sorry I should have included this in my post. This is the image and DOP in the “sin bin” (Recycle Bin)
That is an image with just one copy not three, the VCs went from the DOP before the image made it to the Recycle Bin.
But that doesn’t fit with my comment above, the extra VCs cannot emerge from nothing so one of us is doing the tests incorrectly.
The notion that PL8 is suddenly going to get confused does not make sense.
DxPL is not magical nor particularly sensitive.
Like the FolderMonitor program I used above it is always “watching” the directory currently open in DxPL, no more but certainly no less and it will see items leaving and arriving and, in my tests, tends to handle those events successfully (unless the ‘Date Modified’ doesn’t look like something beyond the last time it looked when it will ignore the item as if no event occurred at all!?)
So after the Remove, with the directory open in PL8, we have
after the Restore from the Recycle Bin we have
and the watching program shows
2024-11-14 22:14:15.571: Starting Folder Monitor V1.4.0.1
2024-11-14 22:14:15.571: .Net Framework Version: 4.0.30319.42000
2024-11-14 22:14:15.571: ------------------------------------------------------------------
2024-11-14 22:14:15.571: Loading settings from C:\Users\bhtho\AppData\Local\NodeSoft\FolderMonitor\FolderMonitor.xml
2024-11-14 22:14:15.576: C:\Users\bhtho\AppData\Roaming\DxO\DxO PhotoLab 7\Database activated
2024-11-14 22:14:15.576: F:\___Beta DXO PL5 - Tests Additional\Test 45 - Simultaneous opening activated
2024-11-14 22:14:15.576: F:\___Beta DXO PL5 - Tests Additional activated
2024-11-14 22:14:15.576: Create notifiers
2024-11-14 22:14:15.655: Starting Background Check
2024-11-14 22:14:15.656: Create BackgroundCheck thread...
2024-11-14 22:14:15.657: BackgroundCheck thread started
2024-11-14 22:14:15.657: Init finished
2024-11-14 22:14:15.657: BackgroundCheck thread running
Restore the file from the Recycle Bin
2024-11-14 22:17:37.945: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG created
2024-11-14 22:17:38.046: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
2024-11-14 22:17:38.116: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop created
2024-11-14 22:17:38.248: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting modified
2024-11-14 22:17:40.986: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG modified
2024-11-14 22:17:41.033: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG modified
As for PL710, new directory with 1 image and 2 VCs
Remove in PL710
The Recycle Bin contents don’t look very encouraging!?
Restore from the Recycle Bin yields
How some of the results reported in this topic are happening I do not know!?
The watching program shows
Creating new Test Folder
2024-11-14 22:27:35.766: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\New folder created
2024-11-14 22:27:35.813: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling modified
2024-11-14 22:27:50.728: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\New folder renamed to F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710
2024-11-14 22:27:50.753: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling modified
Adding a file to the new test directory
2024-11-14 22:29:12.925: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2 created
2024-11-14 22:29:12.948: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2 modified
2024-11-14 22:29:13.255: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2 modified
2024-11-14 22:29:13.732: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
Create 2 VCs and assign Ratings to each of the 3 copies in turn
2024-11-14 22:29:32.552: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop created
2024-11-14 22:29:32.577: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop modified
2024-11-14 22:29:32.584: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:29:42.909: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop deleted
2024-11-14 22:29:42.938: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:29:42.971: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop created
2024-11-14 22:29:42.997: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop modified
2024-11-14 22:29:43.005: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:30:20.712: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop deleted
2024-11-14 22:30:20.752: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:30:20.780: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop created
2024-11-14 22:30:20.812: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop modified
2024-11-14 22:30:23.719: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:34:04.107: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop deleted
2024-11-14 22:34:04.255: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:34:04.466: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop created
2024-11-14 22:34:04.656: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop modified
2024-11-14 22:34:04.656: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
Delete [m]aster from directory
2024-11-14 22:34:04.861: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2 deleted
2024-11-14 22:34:05.002: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:34:05.119: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop deleted
2024-11-14 22:34:05.198: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
Restore from Recycle Bin
2024-11-14 22:38:02.443: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2 created
2024-11-14 22:38:02.474: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:38:02.506: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.RW2.dop created
2024-11-14 22:38:02.573: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
2024-11-14 22:38:05.532: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.xmp created
2024-11-14 22:38:05.583: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710\P1138219.xmp modified
2024-11-14 22:38:05.583: F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 03 - Testing PL710 modified
Always a wise move but in my tests PL8 and PL710 were left open and with the directory from which the data had been removed still selected, to see if anything untoward was going to happen.
I’m confused. Perhaps we are struggling with different issues.
In my case, I accidently deleted a “master” image along with a virtual copy. I intended to delete the VC only. My workaround is to close PL before recovering the accidently deleted files. This recovers the “master” file and adjustments, but no VCs.
This does not appear to overlap the issue others are reporting of multiple VCs created…
…
For anyone interested in studying the dop changes made by PL during this recovery process, here are the “as deleted” and “after recovery” versions from a re-test today. (tested on a culled scrap image with arbitrary edits)
Both image versions had the local adjustment labeled “Hawk2” at line 638 in both files, with VC containing the 2nd local adjustment labeled “SKY” at line 1198 as seen in the “as deleted” version. There are other corresponding differences consistent with the data for the VC version dropped.
DSC05450.ARW - after recovery.dop (12.0 KB)
DSC05450.ARW - as deleted.dop (22.2 KB)
I don’t have the software/system chops to study further.
Thank you all for checking your systems and offering suggestions. I am comfortable with the “workaround” of recovering the “master” image adjustments only (no VCs).
YMMV
Thank you!
@swmurray I didn’t think I was confused about what I was investigating and wrote about the basic problem here Why can I not just delete the [M]aster copy and leave any other VCs (Virtual Copies) intact!?.
But I appear to have caused you upset by my excessively long analysis, sorry.
Because I was running the monitor software it slowed things up a bit and I saw VC[2} being deleted (and removed from the screen), followed by VC[1} and then followed by the [M]aster, until the Test directory was empty.
Unfortunately each of those actions appears to have created a new DOP, which overwrites the previous DOP, so at the end of the exercise only the image and the DOP in its final state DOP reside in the Recycle Bin and are available for restoration.
It is thanks to @SAFC01 that the DXPL(Win) situation was evaluated.
My posts were to simply to show exactly what is possible with PL7-10 and PL810, i.e. that you can recover only the [M]aster after the situation reported by you.
At least that way the all important image is recoverable, complete with the edits made to that particular copy.
Regards
Bryan
No, not upset at all. I just don’t have the skills to track what is happening at the file creation level or in the database. That part is, unfortunately, a black box to me.
So far, others don’t seem to have the same error on a recovered file. Don’t know why, but in my blissful, non-software world, just glad to have a work around.
While trying to stumble on a workaround I poked my nose into the dop files and noted the dop changes. The deleted/recovered dop files checked before reopening PL8 showed lines with the VC-only local adjustment name I was using to check. These were recovered. The dop files did not “update” before the delete/recover. The dop changes occurred after PL8 was opened and the file(s) were “re-discovered”. This seems different than what you describe, so simply offering as a data point. I cannot explain this behavior.
Actually, I appreciate that you and other software-skilled folks are investigating these type issues. That helps me, and perhaps others, learn a bit about the “black box”.
Thanks!
This is a lot different and makes no sense according to my tests and their outcome. Having the database open when I do the ‘Restore’ should have no impact on the data, i.e. the only data available is what is in the DOP.
So a repeat test concentrating on DOP contents rather than on DOP files being created and deleted
So the image copies are ‘Rating’ coded and ‘Colour’ coded
and this is the DOP at the end of this part of the test
P1112346.JPG.dop (27.3 KB)
with the [M]aster, followed by VC[1] and finally VC[2] and this is the summary from an analysis program I wrote a few months ago, but extended to include ‘ColorLabels’, if any are found.
I made a copy of the DOP at that stage and it is named “P1112346.JPG.dop.sav”.
The output from the program contains a lot of debugging information so that I can verify its processing.
[17:55:58] Path = F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting
[17:55:58] DOP file Analysis running
[17:55:58] UserLog title = FolderULog_201115_175558 DebugLog title = FolderDLog_201115_175558
[17:55:58] GFL-01 FileName = P1112346.JPG
[17:55:58] GFL-01 FileName = P1112346.JPG.dop
[17:55:58] GFL_05 Full FileName = F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop
[17:55:58] GFL-01 FileName = P1112346.JPG.dop.sav
[17:55:58] 15/11/2024 - F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop
[17:55:58] (10) File = P1112346.JPG.dop
[17:55:58] (11) Path = F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting
[17:55:58] (20) FileName = P1112346.JPG.dop
[17:55:58] (21) F_File$ = P1112346.JPG
[17:55:58] (22) F_File$_1 = P1112346
[17:55:58] (23) F_Ext_dop = dop
[17:55:58] (24) F_Ext_RAW = JPG
[17:55:58] (30) FileName = F:\___Beta DXO PL5 - Tests Additional\Test 30 - DOP handling\Test 02 - Deleting\P1112346.JPG.dop
[17:55:58] @ line 2 Date = "2024-11-15T17:54:07.8236877Z",
[17:55:58] ----------------------------------------------------------------------------------
[17:55:58] @ line 8 ---->Albums = "",
[17:55:58] @ line 9 CreationDate = "2024-11-15T16:41:33.7325729Z",
[17:55:58] @ line 20 ColorLabel = "Red",
[17:55:58] @ line 21 ModificationDate = "2024-11-15T16:41:33.9988152Z",
[17:55:58] @ line 22 Name = "P1112346.JPG",
[17:55:58] @ line 28 Rating = 1,
[17:55:58] @ line 496 Uuid = "33BEA71C-55CE-4FFE-B051-522FB17EEB56", <----
[17:55:58] Album_count = 1 Uuid_count = 1
[17:55:58] ----------------------------------------------------------------------------------
[17:55:58] @ line 500 ---->Albums = "",
[17:55:58] @ line 501 CreationDate = "2024-11-15T17:53:23.9807518Z",
[17:55:58] @ line 512 ColorLabel = "Green",
[17:55:58] @ line 513 ModificationDate = "2024-11-15T17:54:07.8226852Z",
[17:55:58] @ line 514 Name = "P1112346.JPG",
[17:55:58] @ line 520 Rating = 2,
[17:55:58] @ line 988 Uuid = "C3C30CAC-FA81-4894-8751-60EC2C8C24AB", <----
[17:55:58] Album_count = 2 Uuid_count = 2
[17:55:58] ----------------------------------------------------------------------------------
[17:55:58] @ line 992 ---->Albums = "",
[17:55:58] @ line 993 CreationDate = "2024-11-15T17:53:27.5495877Z",
[17:55:58] @ line 1004 ColorLabel = "Yellow",
[17:55:58] @ line 1005 ModificationDate = "2024-11-15T17:54:07.8226852Z",
[17:55:58] @ line 1006 Name = "P1112346.JPG",
[17:55:58] @ line 1012 Rating = 3,
[17:55:58] @ line 1480 Uuid = "4EEE4656-F780-4407-AB2D-936797FDC6B0", <----
[17:55:58] Album_count = 3 Uuid_count = 3
[17:55:58] ----------------------------------------------------------------------------------
So I then delete the [M]aster, but whatever you do don’t use the Shift Delete command (I believe my testing showed that if you did that while in PL8 the image is deleted and nothing is placed in the Recycle Bin), which will delete the image and the DOP and it should find its way to the Recycle Bin
and this is the DOP of the image in the Recycle Bin
[18:01:51] ==================================================================================
[18:01:51] 15/11/2024 - F:\$RECYCLE.BIN\S-1-5-21-261287212-1455681041-875733364-1001\$RK80G1J.dop
[18:01:51] (10) File = $RK80G1J.dop
[18:01:51] (11) Path = F:\$RECYCLE.BIN\S-1-5-21-261287212-1455681041-875733364-1001
[18:01:51] (20) FileName = $RK80G1J.dop
[18:01:51] (21) F_File$ = $RK80G1J
[18:01:51] (22) F_File$_1 = $RK80G1J
[18:01:51] (23) F_Ext_dop = dop
[18:01:51] (24) F_Ext_RAW =
[18:01:51] (30) FileName = F:\$RECYCLE.BIN\S-1-5-21-261287212-1455681041-875733364-1001\$RK80G1J.dop
[18:01:51] @ line 2 Date = "2024-11-15T18:01:09.5273404Z",
[18:01:51] ----------------------------------------------------------------------------------
[18:01:51] @ line 8 ---->Albums = "",
[18:01:51] @ line 9 CreationDate = "2024-11-15T16:41:33.7325729Z",
[18:01:51] @ line 20 ColorLabel = "Red",
[18:01:51] @ line 21 ModificationDate = "2024-11-15T16:41:33.9988152Z",
[18:01:51] @ line 22 Name = "P1112346.JPG",
[18:01:51] @ line 28 Rating = 1,
[18:01:51] @ line 496 Uuid = "33BEA71C-55CE-4FFE-B051-522FB17EEB56", <----
[18:01:51] Album_count = 1 Uuid_count = 1
[18:01:51] ----------------------------------------------------------------------------------
The image in the Recycle Bin has a ‘Rating’ of “1” and a ‘ColorLabel’ of “Red”, i.e. it is the [M]aster image that remains intact in the DOP.
@swmurray Quite what you are doing to get the result you appear to be getting I do not know because each and every test that I run yields the same results.
This time I closed PL8 and Restored the image and DOP, re-opened PL8 and navigated to the original directory and found this
The program used to interrogate the DOP was originally intended to analyse Mac DOPs looking to determine the ordering of copies within the DOP.
It still needs tidying up but saves me having to go digging through the DOP manually.
Looking at the sidecars, I found that the “as deleted” copy contained the settings of the VC, while the “after recovery” copy had no settings for a VC.
In my opinion, this can mean that PhotoLab
My tests (on macOS) that I did with disabled automatic import and export of sidecars showed no unexpected behaviour. I’d therefore recommend that someone with a Win computer (and some spare time) test the recovery with manual import and export of .dop files. My bet would be that under these settings, the restore should also bring back the VCs. Can someone please check this?
My examples above show that the DxPL(Win) DOP in the Recycle Bin has only the [M]aster edits so no amount of clever importing can bring back something which is no longer there.
The second program output is of the DOP as it lies in the Recycle Bin and it has only one set of edits.
@BHAYT , can you please test with manual import and export of sidecars?
This could give us another peace in the puzzle…that DxO should solve asap.
Steps:
Update
Original text: Just ran a test with multiple deletes and restores and automatic I/E…which resulted in a big mess and mixup of images with no VCs or multiple VCs, even though each image had exactly one VC before deleting.
Correction/comment: I’ve re-tested different scenarios and found that every combination I tried delivered the expected results as reported here.
@platypus Apart from the FolderMonitor program not updating the logfile like it normally does.?
What you suggested in your script is going to cause the age old problem with manual DOP I/E, actually with manual DOP Import.
With manual DOP export the deletion will not cause any automatic DOP exports except that the final deletion [M]aster will result in the deletion of the image file and the DOP, which will be in its last manually exported state, i.e. with all three copies in my case.
As for what happens using this as some sort of long term strategy I am not sure. But it is not the way most run DxPL which is with automatic Import and Export set.
With Auto Import set the unwanted VC, a copy of the original [M]aster, would be avoided and the DOP would be protected from the current cascading deletion of VCs until only the [M]aster is left.
But users have then to remember to periodically export the DOPs otherwise they will be left in some indeterminant state.
PS:- If the export wasn’t made when it was then who knows what might be in that DOP, just the [M]aster, some updates to the VC edits but not all of them, it is potentially a game of Russian Roulette!
PS:- After setting on Auto DOP Load, clean up of [M]aster unwanted VC and change to the colour of VC2
There should have been a deletion snapshot here and/or a snapshot of the empty directory.
But who forgot to export the DOP before the deletion (and then restoration).
DPL in macOS does not create any additional VC in my tests. Again, I deleted the images with the respective menu item of DPL and restored the images when DPL was running or not running. In all those “manual I/E” tests, I got no unexpected effects, also not with auto-I and manual-E settings.
See report on more tests here.
Sorry published too soon by accident
Been playing around in Windows quite a bit.
The Save settings in sidecar file (.dop) automatically option is responsible for deleting virtual copies and local adjustments such as … (the images belong to @BHAYT)
With Save settings … deactivated
I was able to delete everything and restore it from the trash right after.
Thank you @Wolfgang for testing this.
I now think that we get the information we’d need for a ticket that might help DxO handle (get rid of) the bug more easily.
I can confirm that Wolfgang’s finding also holds for me. The deleted DOP when using Remove is the same as the DOP I had PL8 export prior to using Remove to delete the image. A simple Recycle Bin Restore of the RAW and DOP resulted in the Master and its 2 VCs being accessible again in PL8.
As I already have an open ticket about this issue I’ll just add these findings to the ticket.
I still consider it a bug, as this isn’t the PL (MAC) behaviour. Furthermore, as I rely on PL8 creating DOPs automatically (I save the RAW images and DOP for long-term retention and don’t rely on the database at all) I wouldn’t find this workaround acceptable. It would place too much onus on remembering to manually force the creation of a DOP at the end of making changes to a RAW image.
UPDATE
Ticket updated with @Wolfgang’s findings.
Thank you!
I tested with
In these tests with DPL 7.10 on macOS, things worked as expected, no VCs were lost on the way to the trash and back to the original folder. No additional VCs were created. Moreover, results seemed consistent, no matter whether I had DPL on or off when I moved the deleted items back to their original folder.
Other than on Mac, win seems to follow this route
