9/14/2023 0 Comments Dropbox macos ventura![]() This initially caused some headaches for system administrators automating the deployment of multiple machines, but eventually solutions to this were implemented. In 2017, Apple updated the OS to require a multi-step user confirmation before installing a kext. This allows Apple to decide who can sign kernel extensions, and allows them to revoke the signing certificate for individual extensions. In 2015, Apple updated the OS to require that kexts be signed by a certificate in the Apple Developer program. So if the File Provider API is so bad, and it's sill possible to load kexts, why doesn't Dropbox continue to use a kext? File Providers allow them to do the same thing, but, as evidenced by this article, there are limitations as to where the files can live, and there are some bugs. Dropbox used to rely on a kernel extension to intercept file access. The File Provider API is one of these system extensions. Apple is developing userspace extension APIs to perform actions that were traditionally handled by popular kexts. "System extensions", in this context, refers to extensions that the OS loads into userspace. Users should prefer solutions that don’t require extending the kernel and use system extensions instead. Kexts risk the integrity and reliability of the operating system. > Kexts are no longer recommended for macOS. here's what Apple currently has to say about them. To answer this question explicitly, it's currently possible to jump through some hoops to run kernel extensions, but Apple has been slowly tightening the requirements over the past few years. However, it seems that Apple provides replacement userspace APIs, but is not really receptive to issues that developers have with them. In general, I am very happy that Apple is on a mission to ban kexts, I don't want closed source third-party code to run in the kernel. So Apple decided that the kauth API should go (probably for other reasons), but more importantly that thirt-party kexts should go. 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. Praying there are good development staff on board.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. Worried that we are getting slowed down by dependence on the past and just dabbling with what's current. I'm an Accordance user since the 1990's.I'm starting to get to a little concerned about development, especially in light of the current syncing solutions that other MacOS and iOS companies are implementing, e.g. I tried to just have my Acc Files folder on Dropbox, but my Acc14 install seems to have corrupted My Notes file, as the content is gone, and Acc13 and Acc14 both give a crash dialogue box upon quitting the app each time. But I also have my iOS and iOS iPad syncing with Dropbox. Also they said some users were using iCloud for their Acc desktop syncing. ![]() Tech supports solution was to let me know that OakTree is coming out with their own syncing website to replace Dropbox. I get the internal Acc browser error when I try to link to Dropbox in the settings. Same exact problems with Acc14 on a new install on MacBook Pro, verses my Acc13 install on my iMac.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |