Isn’t what the IsUbiquitous property (from the MBS plugin) is for? Just set it to false for the files you want to be kept locally.
I don’t know the declare equivalent.
It’s a readonly property. I swear there was a property for preventing this, but I cannot see it at the moment.
I do, and it’s in my App Kit, however I’ll extract enough of it, to make this option freely available to everyone. I’m just going to spend a little more time reading the docs before I start.
You’re right. Even the MBS property can’t be assigned. I don’t use iCloud for storing files either, so I didn’t actually tried to use that.
I’ve looked at other properties given by the plugin and setting the “keep only locally” flag doesn’t seem to exist there. Perhaps it’s just not settable.
However, there are 2 interesting properties extending the FolderItem class:
IsDownloadedMBS: whether there’s a local copy of the file.
IsUploadedMBS: whether there’s a remote copy of the file.
Now, it looks like when a file exists only remotely, Xojo’s “exists” property returns “false”; but it’s still a valid (though “non-existent”) folderitem, so I guess these two methods above would permit to know whether the file actually exists (locally, remotely, both, or not).
Seems that those two items may only be valid for 10.15+ though.
There’s a matching setUbiquitous method:
Indicates whether the item at the specified URL should be stored in iCloud.
1 Like
As usual, after further reading, Apple has made this overly complicated.
2 Likes
It’s really wonderful that nobody except Craig here has had this problem before.
1 Like
I would like to point out though that this is not entirely true. They can’t sync things in the ~/Library directory IIRC which is where you should be putting the users registration info anyway.
2 Likes
We have it for NSFileManagerMBS class in our plugins:
setUbiquitous(flag as boolean, item as FolderItem, destURL as string, byref error as NSErrorMBS) as boolean
setUbiquitous(flag as boolean, item as FolderItem, destitem as FolderItem, byref error as NSErrorMBS) as boolean
I understand, but Sam and I are conversing about what the declares are called.
1 Like
That’s exactly where the registration key belongs but they often save or detatch it from their email to Downloads or Desktop. The program automatically finds it and moves it to app data.
(but not if iCloud finds it first 
)
1 Like
My app https://www.facebook.com/Kintraks has over 10,000 registered users worldwide and another 5,000 trial version users. At least according to my server download records when I release an update.
Out of all these users I’ve received about 60 (frantic) emails from Mac users about data suddenly disappearing which I have no explanation for. The app has been available since 2004 and only since Mac High Sierra has this started happening.
It’s intermittent and hard to replicate but most of the emails have one thing in common, they haven’t used the program for a while and when they opened it everything is gone. They use iCloud.
2 Likes
Ive had it too. Chalked it up to broken permissions. This makes more sense, while not making sense, if you get me…
1 Like
Yup…
Looks like we can obtain the status of the file (exists locally or remotely, is uploading and downloading) from NSURL.
It seems like we can ask the system to download the file using NSFileManager, however I need to do more research to figure out if this is asynchronous or not. If it is, it seems like we’re required to provide a progress interface.
That setUbiquitous message… Doesn’t really explain how to use it, if you want to disable that file from being synced to iCloud. I need to do some more reading to see if I can figure out how to get the remote URL. I kinda get the impression that this API is designed for apps that explicit work with iCloud containers, which of course we’re not.
NSURLIsExcludedFromBackupKey will stop the files from being synced to iCloud (at least according to archived docs from Apple), however I would expect that this key would stop Time Machine from backing up the file, which of course is NOT ideal for user documents.
Yup, the whole thing is really sketchy if you ask me. I would understand “syncing” between machines.
But this thing of deleting local copies of files and storing them only in the cloud… I’d like to think the reasoning behind it is of good intention… However it’s done without the user being aware, and allowing the user to be put in situations where apps don’t work and no-one (except Apple and Craig) knows why.
It also leads to situations whereby the users data is overwritten by new data, because Apple left functionality out.
file.exists should return true, then when the app tries to open the file, Apple should auto download the file and provide progress for the action. At least the user is then aware of this and the app is unlikely to misbehave.
Anyhoe
Conspiracy theory suggests that by putting your stuff on their machines, you end up forced to pay for the chargeable storage, and locked in to Apple.
(Google drive seems to have the same policy - right now it continually tells me my drive is nearly full , despite me deleting nearly every visible file.)
1 Like
iCoud now messes with basic functionality that has worked fine for me for years. Just a simple function to find a unique name for a file no longer works reliably if it is saved to Documents.
For example the program creates jpg files with incremental file names after checking the names of files in the folder.
When looping through the files in the folder it doesn’t find pic_01.jpg because it was moved to iCloud a while ago and has been deleted. So it names the next picture file pic_01.jpg instead of pic_02.jpg and the new picture overwrites the old file on iCloud.
Only by using a Save Dialog can you prevent overwriting duplicate file names in iCloud. This takes away worry free program automation and makes life harder for the user.
You couldn’t do your valued customers of many years a more disloyal service than to have something in your app that deletes their personal files. It’s unforgivable.
4 Likes
I also worry about changing the behaviour of my app. I have over 200 cases of folderitem.exists in the main app.
How should an folderitem.exists work? Do I need to check for every folderitem.exists also if the file is in the cloud? Should .exist have 3 states: yes, no, filenotfound (eh, been too long on thedailywtf) - IsInCloud?
1 Like
This actually seems like a reasonable suggestion to me.
folderitem.exists
- folderitem.existsValue.no
- folderitem.existsValue.yes
- folderitem.existsValue.remoteOnly
1 Like