3 ms·

SugarSync IMHO takes a backwards approach to syncing. Their original model didn't even include historical versions - wrong way syncs destroyed data! The syste

SugarSync IMHO takes a backwards approach to syncing. Their original model didn't even include historical versions - wrong way syncs destroyed data! The system works by observing and then replaying the events (file creation, moves, etc.) observed on one device to others. SpiderOak implements a different approach, having initially built a comprehensive journaling backup. Sync happens as a result of logically combining the journal entries from all available end points. There's no "event replay." The final state for a folder is calculated based based on the user's likely intent from the totality of all actions taken in each folder over time. The set of actions to perform locally on any device is the diff between the calculated end state and the local state. There are still some good points here. The cross platfrom issues mentioned are subtle. (and SugarSync doesn't even support Linux.) For instance, ":" is a valid character in Mac/Linux filenames but not Windows. And the case sensitivity/insensitivity can create conflicts where they wouldn't otherwise exist. For character encoding, Windows is actually the easiest with Unicode natively stored. Mac and most Linux distros use UTF_8 but there's nothing stopping users from dumping a bunch of filenames with arbitrary heterogeneous encodings all in the same folder.

jgmorard 17y ago
The single reason why SugarSync listens to filesystem events is to build the journals and then merge them. I am not sure how that is different, and how that wouldn't match the user's likely intent. You're right about the fact that there wasn't historical versions. But that was a year back. They're here now, have you not seen them? Unicode encoding is very subtle. The difficulty is that there are several different - but equivalent - unicode encodings for the same strings, and the different filesystems use different normalizations to make sure that they can compare their strings byte-by-byte.

jgmorard 17y ago

The single reason why SugarSync listens to filesystem events is to build the journals and then merge them. I am not sure how that is different, and how that wouldn't match the user's likely intent. You're right about the fact that there wasn't historical versions. But that was a year back. They're here now, have you not seen them? Unicode encoding is very subtle. The difficulty is that there are several different - but equivalent - unicode encodings for the same strings, and the different filesystems use different normalizations to make sure that they can compare their strings byte-by-byte.