No and yes.
I’ve been using DxO products since 2007.
I also test DxO products, which we could consider the “yes” part. 
3 Likes
Ahah! To put it plainly, this is pulling the rug out from under PhotoLab, since macOS is deciding which files it wants to remove in order to make room on the disk.
Unless PhotoLab was written expressly for iCloud, that means that the system has no knowledge of which sidecar files belong to which image files and can only delete files based on its own algorithm, presumably size-based. The main problem is that iCloud apps have to be written to deal with document bundles, which are, under the surface, a disguised folder containing several files written to a format that is interwoven with the iCloud APIs. It is not designed for random file types that can exist independently.
Here is a quote from an article by another experienced developer…
Adding support for iCloud to your application is not just another feature you’re adding. Instead, it is a decision that has far-reaching consequences on the design and implementation of your application. It influences your data model as well as the user interface. So don’t underestimate the efforts of properly supporting iCloud
This reinforces my opinion that DxO is unlikely to do anything about it.
The problem is that PhotoLab is not doing the deleting - that is down to the storage optimisation algorithm and which files out of an image, a DOP and an XMP combination cannot be predicted.
Actually, macOS, per se, doesn’t see them on the disk, Finder keeps track of them in its database and displays a placeholder with the cloud icon to indicate that they are in the cloud but need downloading, which is not an automatic procedure for documents not managed by non-iCloud apps.
@Joanna unfortunately this is not true.
I simulated this procedure - without iCloud offloading - by closing PL, removing the .NEF and then launch PL again and that results in PL deleting the left over .dop file.
1 Like
Well, yes and no. I know what you mean but I am talking about it being macOS deleting the NEF that then prompts PL to delete the sidecar.
As I’ve tried to explain, PL is totally unaware of cloud-based files. It only sees them when they are downloaded to a physical disk. Unfortunately, this is far from a “simple fix”, requiring immense restructuring of PL’s file management to accommodate this behaviour - which would only be for the few Mac customers who choose to try to store image files via the iCloud mechanism.
Also, I guess, you are using a separate folder for testing rather using storage optimisation of the desktop.
Yes. I simply simulated the behaviour on the desktop.
I don’t use any off loading myself. Just wanted to see what PL does to the .dop when the .nef is gone.
1 Like
Would it be so difficult for PL to ask “hmmm… I’ve got a DOP I can’t match with a file here. I want to delete it to clean up but better check with the user that they’re not using some file management system that’s beyond me and I should leave it put - here, have a pop up, yea or nay?”
1 Like
Joanna nailed it.
1 Like
This is not for PL to add a full iCloud sync, just to use the correct APIs to browse and open files. Here is an example how a cross-platform API like fopen fails to read off-loaded files, but the MacOS API can: fopen() fails when trying to open … | Apple Developer Forums
I wonder how the Windows version of PL handles the similar OneDrive feature.
On topic for the original question: TM stores also local snapshots in between the backups, so there would have been a good chance to recover the DOP files, but probably not anymore.
And I would also recommend to not put RAW files on synced folders: They will not only take up a lot of expensive space but also delay synchronization because of their size.
Interesting but, on reading the docs for NSFilePresenter, I found this…
Your presenter objects are not notified about changes made directly using low-level read and write calls to the file. Only changes that go through a file coordinator result in notifications
… which, to me, raises the question of at what level the iCloud management APIs are executed and whether any notification is issued/received.
From a quick glance, I would say things could get just as complicated.
I can imagine that DxO would not be all that keen to dip their toes in either scenario, let alone both.
By far the best advice, especially in the case of a disk that is full enough to trigger this kind of unpredictable offloading.
What is the reason why PhotoLab “must” delete sidecar files without user asking it to do it? Why it can not just leave them where they are as Lightroom does?
“I wonder how the Windows version of PL handles the similar OneDrive feature.”
On Windows it seems like the file system is making the applications believe that the file is there (locally). If it’s on the cloud only, a copy is downloaded transparently for the application. It just takes additional time to open the file.
The whole discussion here concerns me a bit as I’m currently considering getting me a Mac and it seems like a flaw if macOS isn’t doing the very same. Just removing files from local storage is kind of weird.
You can just disable it if you know it.
The support is indeed bad for this feature, but other programs don’t don’t destroy anything. I did not encounter any problem other than with PhotoLab in a decade on Mac.
E. g. Lightroom lists such files as unavailable and you can just click to download it. Finder does it automatically. Better to disable it though.
The only problem is what % of Mac users who use it are not aware of this time-bomb if PhotoLab will not care about them by fixing it.
It’s a feature to save drive space for those, who bought a computer with a low capacity drive. I recommend to get at least 4 times the drive space that you currently use. Also, SSDs need some extra space for housekeeping.
- Do not pinch your pennies for drive space and memory!
That’s not the problem if you know it.
Problem is people unaware that PhotoLab might destroy their work.
They can either make all of them aware of this problem or just stop deleting the files. Nobody explained why it deletes them anyway.
It’s a very unfortunate pattern of behavior indeed and DxO should get rid of it in cooperation with Apple…or at least by introducing some database maintenance.
When I delete a file with finder, DPL deletes the sidecar a second later approx. It looks like DPL deletes the database entries for developments at the same time.
Apple’s User Guide is describing the function like this:
I understand that, whatever is stored in iCloud, can be replicated to the Mac. This would mean that, unchecking “Optimize Mac Storage” can lead to data only being on iCloud and not on your Mac - depending on whatever is “enough” space. “Optimize Mac Storage” basically means “Optimize Mac Performance” by keeping copies of files in iCloud on your Mac…which is the contrary of what the unsuspecting user will understand.
This behavior means that it’s a good idea to always have more free space available locally than the files take on iCloud. Still, the function - and the user guide text - are kind of twisted.
attn. @StevenL
I am still convinced that the problem lies with you storing your RAW files on a synced drive, especially since the problem seems to occur when the drive gets full.
- How large is your main disk?
- How much free space do you have on it?
My MBP has a 1TB SSD and was starting to get full, so I bought an external USB-C SSD and transferred all my images to there. I also have a second ordinary external disk that I clone the SSD to every time I add files to it.
The SSD is lightning fast and I can’t tell it is external. And I don’t have to pay Apple anything for iCloud storage.
1 Like
The destructive action is not the automatic space optimisations by Apple but the automated deletion of the .dop file.
It do not really matter if the file was moved manually by will, mistake or by an automated decision - the destructive action by PL is the same - automated and without needed confirmation.
The file location by itself should not be a factor in any way. Being a good, less good or bad place or simply right or wrong place. 
@myneur should perhaps just post a feature request / bug report asking DxO to have PL not auto delete files.
Personally I’m quite structured and a bit “cloud cautious” which both reflects my personal choices and professional path regarding integrity and security.
2 Likes
I’m not doing it anymore. I turned that off.
The problem is that other people are not aware of this bug and PhotoLab can destroy their work.
As I said, PL can make all the people aware and make them change their behavior or just stop deleting files.
I thought this forum is for that. That I’m supposed just to tag it as a bug. Are bugs reported elsewhere? Where?
But then you may be back in the o
problem of dops not being deleted when you DO delete imiges in PL