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.
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.
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…
@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.
@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:
