You are taking strong positions on what is right or wrong when there is no objective answer and tradeoffs both directions.
> It is a user's responsibility to insure that a symlink will work elsewhere; cloud services should just copy the file, just like any other. The users who expect a symlink to trick a cloud service into special behaviour (like syncing folders elsewhere) are also wrong. You no more want a cloud service going off and "thinking" about a symlink, than you wanting it going off and "thinking" about porn it finds on your computer. These are just files; their contents or meaning are absolutely not any cloud service's concern.
Unison seems to be more designed for personal sync'ing than collaboration. That informs decisions.
If you take your position that symlinks should be sync'd opaquely (as a file with a symlink target), collaborative relationships that involve symlinks are broken without much warning when a collaborator uses windows XP (the most popular OS when Dropbox came out!).
At least following them (which Unison does allow with a setting) ensures Windows collaborators can see them.
Dropbox could probably make the change now (few XP users remain), but you have legacy issues of existing users relying on the "follow" behavior to sync content outside of their Dropbox.
> One can declare a directory atomic, forcing the user to choose at the directory level when there’s a conflict.
Not forcing users to make choices before upsync occurs is an explicit design decision of Dropbox. It ensures that if I power on my computer after being offline, things will quickly sync to the cloud -- I don't need to spend time making decisions.
>symlinks to Windows (or at least WinXP since they didn't exist until Vista)
The version of NTFS in windows xp and the version of windows explorer both supported symlinks just fine. There was just no user-mode api to create them. You could use a kernel driver to make them, or even mount the disk offline and make them
> It is a user's responsibility to insure that a symlink will work elsewhere; cloud services should just copy the file, just like any other. The users who expect a symlink to trick a cloud service into special behaviour (like syncing folders elsewhere) are also wrong. You no more want a cloud service going off and "thinking" about a symlink, than you wanting it going off and "thinking" about porn it finds on your computer. These are just files; their contents or meaning are absolutely not any cloud service's concern.
Unison seems to be more designed for personal sync'ing than collaboration. That informs decisions.
First off, Unison cannot sync symlinks to Windows (or at least WinXP since they didn't exist until Vista) (http://www.cis.upenn.edu/~bcpierce/unison/download/releases/...).
If you take your position that symlinks should be sync'd opaquely (as a file with a symlink target), collaborative relationships that involve symlinks are broken without much warning when a collaborator uses windows XP (the most popular OS when Dropbox came out!).
At least following them (which Unison does allow with a setting) ensures Windows collaborators can see them.
Dropbox could probably make the change now (few XP users remain), but you have legacy issues of existing users relying on the "follow" behavior to sync content outside of their Dropbox.
> One can declare a directory atomic, forcing the user to choose at the directory level when there’s a conflict.
Not forcing users to make choices before upsync occurs is an explicit design decision of Dropbox. It ensures that if I power on my computer after being offline, things will quickly sync to the cloud -- I don't need to spend time making decisions.