Vanilla 1.1.9 is a product of Lussumo. More Information: Documentation, Community Support.
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?
The best is you file a feature request in our bug tracker (http://mantis.the-soulmen.com) and add the things you'd like. We'll then see what we could do ;)
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...
Actually we don't use resource forks. There must be some other issues maybe with concurrency or so. However, DropBox works almost perfect most of the time. Whenever there is a problem, you can simply revert to a backup project...
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 have to add -- that after using Dropbox with Ulysses for two months now, I once had the occasion that a whole document was just gone. Not sure what the reason was, but that whole folder for the document was just gone. Luckily it was almost empty. However, everyone using Ulysses with Dropbox is at danger there...
Where is the built-in secure syncing facility??
...
...
<writing reminder to self>
1 to 15 of 15