From Cyberdog to dataless files: a brief history of iCloud
eclecticlight.co
eclecticlight.co
So if you want your files to be synced and to be 100% sure you'll have a local copy - you should keep the same file in iCloud Drive and in the "On My iPhone" folder. This is the reason Apple Books, Numbers and all the apps that use iCloud Drive remove local copies all the time.
I made a simple note-taking app using iCloud Drive - iCloud was greedily removing a 2 kb txt-file when the app was closed (sometimes it wasn't removing - it's quite random). It doesn't matter if you have a lot of storage space - iCloud still can remove the local version of a file you constantly use.
The Apple developer support said nothing can be done. Even for a developer there is no way to mark a file as never to be removed
P.S. In their official docs Apple actually recommends to keep all the user's files in iCloud Drive and _not_ to keep a copy "On My iPhone"
Switched to OneDrive and android now. Keep offline works.
Not to my experience. Books just need to be downloaded once, and they stick.
Maybe it's based on some calculation like available device space?
Cyberdog had instantaneous indexed search for local text, which combined really well with tech mailing lists that were really popular back in the day.
That didn't become a part of the feature set on Windows until Windows Vista shipped a decade later.
Was that what eventually became V-Twin, and then became Spotlight indexing? I vaguely remember that from the Cyberdog/OpenDoc days. I always wanted to play around with it, but it was so memory intensive for the Mac I had access to at the time. It seemed amazing though, like a big step up from OLE (in terms of technology).
fileproviderd (a launch agent on macOS and a daemon on iOS) watches the FSEvents stream and saves the events in its database. fileproviderd maintains its own sync engine for each provider on the system and will forward events to/from each provider.
Dataless files are an interesting example of Apple using its vertical integration to create an end to end solution that others can’t quite make. Since they own the filesystem, kernel, and user space daemons they can make something that works like this.
This is part of Apple’s years-long effort to kick 3rd parties out of the kernel. As apart of the M1 transition, kernel extensions were no longer aloud and file provider apps were using kernel extensions to intercept file system events at a low level before. Now that they are no longer able to do that, Apple has provided this replacement.
The File Provider API provides a much better admin and user experience, but the storage providers tend to really easily make a confusing mess of it. OneDrive took the time to figure out how to use sync roots in a way that enables you to store your actual data-containing files to an external drive. Dropbox didn’t care about supporting that use case on Macs, so what was once possible with both is now just possible with one. That has been a source of problems for many.
On the other hand the migration to OneDrive’s File Provider implementation was a data-thrashing horror show for many.
And iCloud Drive doesn’t truly let you decide a persistent sync state for everything.
The security implications are better but it’s just the same old mess file syncing has been for a long time :)
(I keep several SSDs connected via USB through a USB-C dock, if that matters to the answer)
macOS enforces that the sync root remain local, but OneDrive does a little bit of slight of hand to be able to store files on an external drive.
There is a write-up from the OneDrive team at [0] that details some caveats on how this works.
OneDrive technical documentation can be difficult to follow since they like to disclose version/dated changes as blogs instead of something more formal and managed.
I believe this is still possible, but experimentation with non-critical data might be advisable.
[0] https://techcommunity.microsoft.com/t5/microsoft-onedrive-bl...
Also, I think you meant allowed not aloud
D'oh! Damnit I hate when I do that, thanks for letting me know. I wish I could still edit the comment..
And vice versa, .Mac was a closed system component without any APIs that developers could use in their applications. I think that came much much later.