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
Well, a destructive actions should never be the default action - this is a classic rule in interface guidelines - and it should only be applied after consent given.
Choosing to delete or remove an asset from within PL should invoke a modal dialog where the default action is non destructive. In PL 6 a dialog is shown but the default action is unfortunetly destructive.
1 Like
I’ve looked into iCloud sync and optimize storage settings. Imo, the best way is to disable syncing the Documents and Desktop folders.
Cloud-centric data processing assumes that data can be found in the cloud to begin with.
- If we want that, we can use Apple’s default settings (that makes D&D folders visible on all devices) and all other folders remain untouched.
UNDERSTAND THAT YOUR MASTER FILES ARE IN THE CLOUD. - If we don’t want that, we need to disable D&D sync, carefully making sure that nothing gets lost in the process.
Space optimization is the wrong term. If checked, cloud files are replicated to the Mac, which can then work all files, even if it is not connected. The setting does not optimize drive space, but enables working offline, provided the Mac’s drive is big enough.
So far, I’ve never paid attention to the setting, because I never synced anything to the cloud, except for a few folders that I created for sharing. I currently use 1 out of the 5 free gigabytes of iCloud space and nothing has been deleted without my consent.
Other than that, it pays to use the predefined folders as labeled…although all my image files are in a folder under the “Shared” user. I use the Desktop as a temporary place to store things that need no backup. Time Machine drive space fills up pretty quickly if a temp folder is backed up…
1 Like
@Joanna The loss of a RAW file with a DOP does not “appear” to result in the automatic removal of the DOP on my Win 10 system, albeit testing was with PL5.6.1!
The DOP is still in place after a name change of the RAW and a bounce of DxPL. This doesn’t help any issue with the MAC version but highlights another inconsistency between the two versions!
I changed the name of another file to .sav with DxPL shut down and the DOP remained after restarting DxPL, so I then moved the .sav files and DxPL continued to leave the orphaned .DOPs alone!
PS:- I opened a directory with 4 images and associated DOPs and moved all 4 image files while in scope in PL5.6.1. The database entries vanished but the DOPs remained intact!
So a little untidy maybe but …
I wonder how many of us would answer “yes”, if a poll would ask “do you regularly use your desktop to store RAW files you’re working on?” And “do you host your RAW files in a cloud service?”. But I might be wrong and people are already keen to give up their owner rights voluntarily? Depending fully on the grace of a cloud hoster and a well-working internet connection is a weird thing to do for me.
If I need to work for whatever reasons on another machine, I use airdrop at home or a SSD when abroad. And I steer clear of iCloud or OneDrive for a lot of good reasons imo.
How could Mac OS know that an app needs tiny .dop files AND saves edits in a database and all of it is gone after syncing a file with the same name and different extension to iCloud? And why can’t PL not track RAW files on their journey to iCloud? Well, it’s concept is from a different era and never made the step into cloudy times.
1 Like
@JoJu Why should it and it is a partial move anyway, i.e. the “detritus” of xmp sidecar file and DOP have been left behind!!
Regardless of how “smart” DxPL is or not the DOP and sidecar file survived a night alone and another restart of PL5.6.1 (and the behaviour seems to be consistent with PL6.1.0) on my Win 10 system!
So I would raise a bug report requesting that the Mac version is as “lazy” as the Windows version and leaves any such “detritus” alone, thereby enabling the user to re-unite them at some point in the future and present the complete picture to DxPL once re-united.
In my case the database entries have certainly been “tidied” up automatically because the directory in question was “in scope” i.e. I had been editing it before I “spirited” the image files away!
So the edits have been lost to the database, but only if the directory in question has been “visited” since the loss occurred, as far as I know DxPL does not regularly “sweep” the database looking for “detritus” to remove.
So for “safety” “park” your cursor in DxPL on an empty directory, i.e. it can have subfolders full of images but it should have none itself! But most troubling incidents of this nature are only discovered when DxPL is used to continue editing where the user left off!!
CAST YOUR VOTES HERE:
1 Like