[Brian]

Mark, the troubling part here is that the older MobileMe version of your iDisk claims to be one byte of data. Don't pick that version.

It looks like you've reproduced the iDisk syncing problem; if you open up console.app, are there any messages that look related to the sync process?

We have a pretty good handle on *what* is happening here - iDisk gets confused and blows away your data; this makes it look like it's happening on the iDisk servers.

The next step is to figure out *why* this is happening so we can work around the problem. Any messages in your console log might help us do that.

(I also responded to the support ticket you sent in - if there is console info, please send it via email.)

[MacBerry]

Well, there are loads, but I don't know what to look for, and couldn't possibly send you everything.

I'm working at the moment, and will be for the next 2 hours at least, but after that will gladly give you VNC access to my machine if you want (it's all set up - you just need the url, the port number and password) to have a look around in Console for yourself? e-mail or PM me if you want to do that. I'm in the UK and it's 21:14 now - I'd need my machine back by 7 am!!

Remember I sync 2 macs to iDisk, so I guess that could compound the issue.

Mark

[Brian]

Originally Posted by santra

2. Turn on iPhone OF and sync--only to discover the sync produces incorrect data.

The issue that folks are running into is caused by a copy of OmniFocus starting up after several hours of inactivity and reviewing actions in the existing database for status changes that happened during that time.

When there are sync conflicts between the changes the app made on its own and the changes the sync server specifies, it decides in favor of the changes it made. This is what causes information from your sync to disappear. The bug has been fixed in current versions of the desktop app. Once 1.0.3 is released, the iPhone version will no longer make this mistake.

One thing it's important to make clear, though, is that sync conflicts in OmniFocus are record-based, not field based. We do this for performance reasons: field-based conflict resolution would make sync take much, much longer.

What does this mean? If you sync two machines, then edit an action on both machines - change the note on one machine and the start date on the other - and then sync both machines again, you're not going to see each machine get the change from the other machine. You're going to see one or the other change win out over the other.

I suggest that folks sync before they start editing on a device, and push those changes back up to the server once you're done. It makes your syncs quicker by reducing the number of change files we process during any given sync. It also means you're more likely to get the results you expect, since there are fewer sync conflicts to resolve.

[braver]

Originally Posted by Brian

The issue that folks are running into is caused by a copy of OmniFocus starting up after several hours of inactivity and reviewing actions in the existing database for status changes that happened during that time.

When there are sync conflicts between the changes the app made on its own and the changes the sync server specifies, it decides in favor of the changes it made. This is what causes information from your sync to disappear. The bug has been fixed in current versions of the desktop app. Once 1.0.3 is released, the iPhone version will no longer make this mistake.

One thing it's important to make clear, though, is that sync conflicts in OmniFocus are record-based, not field based. We do this for performance reasons: field-based conflict resolution would make sync take much, much longer.

What does this mean? If you sync two machines, then edit an action on both machines - change the note on one machine and the start date on the other - and then sync both machines again, you're not going to see each machine get the change from the other machine. You're going to see one or the other change win out over the other.

I suggest that folks sync before they start editing on a device, and push those changes back up to the server once you're done. It makes your syncs quicker by reducing the number of change files we process during any given sync. It also means you're more likely to get the results you expect, since there are fewer sync conflicts to resolve.

Brian -- this is important, can you please specify exactly the granularity -- action? So everything about it -- project, context -- should be OK?

[santra]

What wolf said. And the amount of time it eats up is unbelievable.

I'm spoiled, I guess: OS X and Mac Apps are generally so stable and awesome.

But "sync is hard to get," as they say.

Unlike wolf, I am not willing to give up. I got through the entire OF alpha last winter, and I'll get through this iPhone crisis.

Now it's time to blow away ofocus files again! (2nd time today)

Originally Posted by wolfneuralnet

I have to go through the exact same procedure as Santra above every morning to make sure I have a good sync, and I DO NOT have iDisk syncing turned on.

For a productivity app, this is really unacceptable, as it is eating a lot of my time. I may just give up on the iPhone app until this is straightened out.

[santra]

Originally Posted by MacBerry

Umm, just a little reminder - OF 1.1 for desktop is still an alpha app, and is completely free to use at the moment. IMHO it's one of the most stable alpha builds anywhere.

Agreed! It's been excellent!

Originally Posted by MacBerry

There's less defence for the iPhone app I suppose, as it's not sold as alpha or beta

Exactly. That's why it's a little ironic: the app that's beta is working great, the app that's public and being sold on the iTunes store is trouble--well, at least if you're syncing.

[MacBerry]

Originally Posted by santra

Exactly. That's why it's a little ironic: the app that's beta is working great, the app that's public and being sold on the iTunes store is trouble--well, at least if you're syncing.

Well, except that the syncing bit really is declared as alpha, because it needs an alpha product on the desktop.

But more to the point, I think it's looking more and more as if the issue lies largely, if not completely, with MobileMe/iDisk, not OG. Given the fiasco that was the launch of MobileMe, that's hardly surprising.

I'm very very tempted to set up a WebDAV on one of my (always on) macs, and sync OF using that instead of MobileMe, which I'll leave to the native apps. The only things stopping me are the time involved, and the feeling that if I continue to sync via MobileMe I'll maybe be helping OG find and fix or work around the issues.

Mark

[Lizard]

As much troubles as you've had, Mark, I think setting up the WebDAV might save you time in the long-run.

http://manas.tungare.name/blog/2008/...cus-to-iphone/

[Andrew]

Braver, granularity is at the level of an item. So changes to an action on one side and its project on the other should not conflict. Some cases can be a bit ambiguous, such as reordering actions - is that a change to the parent (project or parent action, as appropriate), or to the reordered actions? For our purposes, that is considered a change to the parent, so for instance if you update the notes for a project on one device and reorder that project's actions on another device and then sync, either the note change or the reordering will be lost, depending on which change was made most recently.

[Brian]

Originally Posted by braver

Brian -- this is important, can you please specify exactly the granularity -- action? So everything about it -- project, context -- should be OK?

I'm not a developer, so I'm not really qualified to answer at this level of detail. I know some other folks are working on posting more info about how sync works, though.

Here's what I do know: if you avoid sync conflicts by syncing changes to a device before you changing anything in OmniFocus, and then push those changes back to the server before switching to another copy, your syncs will be faster and will you will have a smaller chance of getting unexpected results.

Start up OmniFocus and pull all the changes down from the sync server before you start changing things. Change things; doesn't matter what. After you make changes, send them back to the server. Switching between 2, 10, or 100 machines will work better this way. Order doesn't matter.

Think of it like a sandwich - all your changes want to be a tasty layer of goodness cushioned between two delicious, fluffy syncs. Your server can hold an infinite number of sandwiches which come in any order from your machines.

If you start interleaving your sync sandwiches, though, things get really messy really fast.