@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.
- DxPL discovers an image with a DOP but is not allowed to read and Import the DOP so it allocates a new UUID
- The user then imports the DOP and instant Unwanted VC results, at least one reason for not having manual imports. A slightly more sound strategy would be automatic imports and manual exports
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).