4 ms·

Not familiar enough was Dropbox was able to mount on "/" ??? As others and the suport page pointed you, you can still put a symlink at any available location y

Not familiar enough was Dropbox was able to mount on "/" ??? As others and the suport page pointed you, you can still put a symlink at any available location you want. It's still fully usable but it's now garanteed to not mess around with others contents. I personally am an iCloud Drive user at home because if I already chose to trust Apple for the OS and all, using their (contractually paid for) sync service doesn't require me to trust another party. Standardization and sandboxing of cloud providers actually make me think about subscribing to a third party (for diversification let's say, or for separation of concerns when sharing on pro/other context). Because if standardized I can be assured by OS policy that theses sync services won't fuck around anywhere else than in their designated folder. So yeah, maybe from now on you'd better go for rsync based tools that don't target App Store for pro use. But for 90% of the target audience this might actually be a desirable feature.

Kwpolska 4y ago
> Not familiar enough was Dropbox was able to mount on "/" ??? No, but what the OP meant was that Dropbox users think of it as a replacement for an external hard drive with all your projects. (Myself, I consider Dropbox, OneDrive, and iCloud Drive, to be the same thing with a different corporate overlord, and I migrated from Dropbox to OneDrive without any changes to my workflows…) > It's still fully usable but it's now garanteed to not mess around with others contents. How would it mess around before? Do you have any examples?
- Twisell 4y ago
  I can't point out a specific bug/vulnerability because I don't follow them that closely on platforms I don't use. It's just that globally I'm not fond of background processes that run without being properly sandboxed through the OS. I'm less regarding when using FOSS software but for commercial closed source solution like dropbox I'd rather have them run with limited privileges.
  - shortformblog 4y ago
    These are two different arguments. You’re arguing for a level of security; I’m arguing that Apple’s implementation did not consider real-world use and leads to end-user compromises that lessen the experience. In particular, I point to the move that you have to now keep the storage on the main drive, and the move to block access to the Mac’s photos library. Neither of these moves were necessary for sandboxing reasons. Both degrade the experience for Dropbox users that may have a folder far larger than the 256GB many base Macs come with. Apple could have accounted for use cases of this nature to allow them to make sense for existing Dropbox users. They didn’t. Sandboxing can be good in theory but completely suck in execution. That, I argue, is what happened here.
    - Twisell 4y ago
      Leaving a third party Interfer with Photos library can easily lead to corrupted database and sync error if iCloud Photo library is enabled or worse if someone tried to access "Apple managed Photo library" from 2 different devices at the same time (the latter being a typical use case of dropbox). So this make a lot of sense, if you want to share a photos with drop box you should configure "Apple Photo library" to keep files in place instead of including them in database and sync that folder. Or you are even better using an other photo management app that support ACID database consistency accros dropbox file sharing (which is actually not an easy problem). Actually to share photos with dropbox you are maybe even better off syncing flat jpg files and use applications that don't rely on database at all on your different devices. A friend of mine do the latter and he's happy with that. I can agree however on your last point, it could have been nice to allow cloud storage to be moved to an external HD. Maybe they should bring back this possibility in a futur update. But for the managed photo library nothing currently prevent you from storing your database in an external drive, it's only cloud storage that is forbidden for the previously mentioned concurrency issues. Please keep in mind that Cloud storage is not an external hard drive storage, it's not local, it's not a backup either (I personally backup regularly files on my cloud storage in 2 separates offline external HD and everyone should at least get one. Otherwise you actually have no backup).

Kwpolska 4y ago

> Not familiar enough was Dropbox was able to mount on "/" ??? No, but what the OP meant was that Dropbox users think of it as a replacement for an external hard drive with all your projects. (Myself, I consider Dropbox, OneDrive, and iCloud Drive, to be the same thing with a different corporate overlord, and I migrated from Dropbox to OneDrive without any changes to my workflows…) > It's still fully usable but it's now garanteed to not mess around with others contents. How would it mess around before? Do you have any examples?

Twisell 4y ago
I can't point out a specific bug/vulnerability because I don't follow them that closely on platforms I don't use. It's just that globally I'm not fond of background processes that run without being properly sandboxed through the OS. I'm less regarding when using FOSS software but for commercial closed source solution like dropbox I'd rather have them run with limited privileges.
- shortformblog 4y ago
  These are two different arguments. You’re arguing for a level of security; I’m arguing that Apple’s implementation did not consider real-world use and leads to end-user compromises that lessen the experience. In particular, I point to the move that you have to now keep the storage on the main drive, and the move to block access to the Mac’s photos library. Neither of these moves were necessary for sandboxing reasons. Both degrade the experience for Dropbox users that may have a folder far larger than the 256GB many base Macs come with. Apple could have accounted for use cases of this nature to allow them to make sense for existing Dropbox users. They didn’t. Sandboxing can be good in theory but completely suck in execution. That, I argue, is what happened here.
  - Twisell 4y ago
    Leaving a third party Interfer with Photos library can easily lead to corrupted database and sync error if iCloud Photo library is enabled or worse if someone tried to access "Apple managed Photo library" from 2 different devices at the same time (the latter being a typical use case of dropbox). So this make a lot of sense, if you want to share a photos with drop box you should configure "Apple Photo library" to keep files in place instead of including them in database and sync that folder. Or you are even better using an other photo management app that support ACID database consistency accros dropbox file sharing (which is actually not an easy problem). Actually to share photos with dropbox you are maybe even better off syncing flat jpg files and use applications that don't rely on database at all on your different devices. A friend of mine do the latter and he's happy with that. I can agree however on your last point, it could have been nice to allow cloud storage to be moved to an external HD. Maybe they should bring back this possibility in a futur update. But for the managed photo library nothing currently prevent you from storing your database in an external drive, it's only cloud storage that is forbidden for the previously mentioned concurrency issues. Please keep in mind that Cloud storage is not an external hard drive storage, it's not local, it's not a backup either (I personally backup regularly files on my cloud storage in 2 separates offline external HD and everyone should at least get one. Otherwise you actually have no backup).