There is nothing to say against DropBox as long as you have backups like ours or Time Machine. Exporting as zip does not really work for us. More or less we're constantly saving your project as you write. This means that the compression would run all the time and keep your CPU quite busy. Not to speak of the dropbox folder that'd restart the upload every few seconds...

Okay, now I understand you better. What we could do without any problems is to add a "compress" option to the project exporter. This would write the project as ususal but compressed. Would this be something?

Perfect ;-)
Perhaps with a date stamp added to the project name?

Interesting, my U files live in my Dropbox repository and are synced across three computers. Haven't had a moments corruption or problem.

madox: but there is some console output that shows you what could not be loaded correctly. So that search should be a bit easier. We plan to lift this up into the interface though...

The issue according to the Drop Box forum is the use of resource forks. This is apparently fixed in the next version of Drop Box.

Just to shed a little light on this, it has nothing to do with resource forks, that DropBox report that they released was erroneous in that aspect. In fact they mentioned the software I work for by name as one of the incompatible ones; we don't use resource forks either. ;) Resource forks may be a problem, but it isn't causing the issue here.

This issue is, as Max speculates, entirely down to concurrence and the very real probability that files will "collide" and end up with versions that have been renamed to "xxx conflicted copy datestamp.etc". With normal files, you can examine both of them and figure out which you meant to keep as the latest, or manually merge the conflicts and save a new copy. With a bundle format, these conflicted files are all hidden from you by default, and if the conflicted files are project control files, it can be next to impossible to merge them or decide which is best.

It's remarkably easy to accidentally end up with a corrupted project like this. All it takes is a laptop that is offline for a while before syncing. Any time you make edits offline, without syncing first, you run the risk of it. Some people never work that way, or always remember to sync before they head out, so they never have a problem. There are things you can do to make sure you never run into it, but it is a risk.

But don't rely on the so-called beta coming out to fix the problem. In fact, that beta is already out and a part of Dropbox-stable these days. It's aimed at a different problem entirely. The issue here is not going to go away unless Dropbox fundamentally changes their conflict resolution. And I hope they don't, frankly. You need conflict resolution, and the only other sane way to handle it is with dialogue boxes, which I hate. I'd rather be able to examine the files at my leisure and solve the problem, and dialogue boxes won't help in unravelling the conflicts in a tightly-knit bundle format, anyway.

I work live on my hard drive most of the time but the backups are synced with Dropbox. To achieve a faster sync and to avoid problems due to the package the Ulysses backup creates i've written a simple AUTOMATOR function. The folder actions automatically compresses the Ulysses backup and places it into my backup Dropbox folder. This is done in no time with a single step within AUTOMATOR.

Cheers!
Sebastian