Monday, March 28, 2011

Jungledisk deletes your data

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.

3 comments:

Anonymous said...

Hi,

We use JD for our work and have noticed data disappearing, which is most inconvenient. JD say that someone must have done it but we have provided evidence to show that this is not the case. I wondered if you might be able to recommend a cloud server that offers a better service?

Many thanks

Jim Corney said...

It's very difficult to qualify "better" service, because it's in a bizarre position of having very good functionality, while being essentially unusable because the development halted.

The closest product I was able to use is CrashPlan. It's not so funcionality-rich, but at least it works fine.

Jim Corney said...

Also, forgot to say. Before CrashPlan, I've been using SpiderOak for an year or so.

I was satisfied enough with it (it has minor bugs as well, but at least "it works"), but it has an architectural problem - it doesn't handle a large (dozens of thousands) number of files.
When you will trigger such situation, SpiderOak will start to hang, making it impossible to use the interface. In addition to that, it's programmed as single thread: this means that even if you have a super-powerful quad-core (which is not an uncommon setup nowadatys), you will notice that one core will be used, 100%, but not the others.

Because of this, I had to eliminate SpiderOak as well. I don't know if this bug has been solved, but my guess is that it hasn't - I waited for months, and they didn't show even a minimal progress.