Yes, the title is correct. There is a bug in the Jungledisk sync which, in not uncommon conditions, will delete your synchronised data across all the computers.
Specifically, if a machine is downloading the data of a synced folder, and you shut down the machine, on the following startup, JD will think that the data not downloaded has been deleted, and proceed to delete it on the servers, which in cascade, will delete it also on your other synced machines.
This of course make the Jungledisk sync unusable - I'm not going to trust code which deletes my data.
You can still go through past backup, but that's very uncomfortable.
In addition to that, JD sync is remarkably poorly coded:
- it has a very long lag, taking long time before detecting changes.
a real use cases is the one where you made a modification to your data, then turn your computer off. while competitors start the sync upload immediately (e.g. DropBox), JD won't, so either you wait minutes doing nothing in front of the computer, or you can forget your syncing. what also happens, is that you may forget to wait, and change the data on another client - you will have to solve the conflicts when you turn your first machine on.
- it has two separate bugs related to non-ASCII characters. one bug is on the folders, and another one on the files; both cases will cause your sync on the folders/files to fail.
All in all, JD's syncing has always been very poor, while being an important part of the application.
Files deletion support request: http://support.jungledisk.com/requests/55573.
Folder syncing support request: http://support.jungledisk.com/requests/50416
At this point I'm really annoyed by filing bugs, so I didn't file the bug for non-ASCII files.
I'm trying SpiderOak now, and if it works well, I won't hesitate a moment before swithing.