However, having third-party code running in kernel space is a huge liability, besides opening a huge possibility for state-sanctioned backdoors, it opens another venue for security vulnerabilities that give kernel-level access. Dropbox did this before using a kernel extension, so that it can hook into the kernel kauth framework. The issue is that you need to intercept file I/O to make transparent sync work. But if dropbox is just another proprietary piece of software running hacks, I can’t really blame Apple. Or at the very least, they could have attempted to publish a standard.

And it's much easier to understand and work with than manually managing selective sync. Why not? It's a very handy feature for a lot of users who don't have the disk space available to store their complete Dropbox folder.

Perhaps shouldn’t exist in the first place

That said, this hack (pretending your files are on disk) is arguably a fragile one, and perhaps shouldn’t exist in the first place (assuming it’s not a networked file system, which I believe it’s not). Dropbox cannot afford to simply throw their hands up and blame the users for not being technical enough. Non-techies will find it incredibly annoying to map individual subtrees leading to missing files, upfront sync costs when you need those, and running out of disk space. I don’t know how others do it, but I assume that you’d have to manually maintain mappings between a subtree in the cloud to one on disk, or alternatively run out of disk space if you want to have everything synced. I agree, but I think it’s important to point out: I believe the main feature they need is to sync the full file tree without having to download the actual files until needed.

Dropbox download mac m1