[Jay Levitt]

I'm trying to follow them, but: did you really mean to "rename" the iDisk copy, and not "copy" it? When I run the script on the desktop, rename the iDisk file, then sync on the desktop, OF asks me "local or server", and I'm not sure which is the right answer in this case..

[Lizard]

We want to push aside the current iDisk file and put a new one up there. So rename it or put it in another folder. (You could delete it entirely, but some people are justifiably nervous about deleting anything that might serve as a backup if things go horribly wrong.)

You run the script on one Mac. Let's call that the alpha Mac. Now you want to replace the data on all the other machines with the one on the alpha Mac. So when you sync the alpha Mac, if you get asked, you want to use the local one. Now the server has the same data as the alpha Mac. So when you're on another Mac, or an iPhone, if it asks you, you want to choose server, so that the data from the alpha Mac gets brought down, replacing the old huge data on the machine you're syncing now.

---

A lot of people seem to get confused about "local" vs. "server". We haven't been able to come up with clearer terminology, but maybe we're just too close to the problem. If anyone has any better suggestions, we're very open to hearing them.

[Jay Levitt]

No, that makes sense (and it's what I ended up doing); I was just confused because you mention the local/server prompt on the second device, but not the first, so I thought it wasn't supposed to appear.

Local/server is a tough distinction, since you're using the iDisk, which appears as a local device AND a remote device! But I think the current dialog is as clear as it could be, given that. I was forgetting that the iDisk copy is not the local database itself, too.

One possibility would be to give me more information about the two files; was one created earlier, or does one have a more recent last-entry, or something like that? In other words, show me one of the differences between the files, so that I will know which copy is the one I care about. That's easier on the Mac than the iPhone, where you have so little real estate; maybe a third "explain further" or "show details" button there?

[Jay Levitt]

PS - is there some way (even manually, from a shell) that I can verify that I've done whatever I was supposed to do? How can I tell a properly-coalesced database from a buggy one?

[Lizard]

If you "show package contents" on your .ofocus file, or cd into it from a shell and look at the list of file names, you can tell a lot about what's going on with your file.

The short answer is, you should have one .zip file in the local copy of your file when it's just been coalesced. And when it gets up on the server, there should be one .zip file and one .client file. Once you start syncing, you'll get some more .zip and .client files, and that's normally okay.

I'm going to put together a reference article with more details on how the file format works and link it here once I finish.

[santra]

Oh, dear...ofocus package is back up to 500K, 150 files, only 2 days after fix reduced it to just 4 or 5 files, package size 40 or 50K.

I guess I have to run this fix every day?

[Lizard]

You shouldn't have to run this fix every day. Only if you change the sync settings on your iPhone (until 1.0.3 comes out) or if stop syncing one of your machines. OmniFocus will automatically coalesce (aka "smoosh") your database when all your Macs and/or iPhones/iPods are syncing regularly.

[Brian]

No: only run the fix if sync slows down on the phone, or if you see files on the sync server that are older than the least recent sync you did on one of your devices.

Amount of disk space isn't particularly relevant to the slowdown; number of files is relevant but only if the sync process bogs down on the phone is the fix worth running.

Probably easier to explain this way: I may do some work from home this weekend, but I won't be in the office. The home machine and the phone will likely sync over the weekend, but my work machine won't.

The number of files will grow all weekend, and this is fine. Each file contains a change to your data. We keep all your changes until the least-recently-synced device does a sync.

However, if I sync my work machine on Monday and see files from the weekend, *that* indicates a problem.

[Toadling]

I see a fair degree of fluctuation in mine, depending on how many changes I make in any given day, ranging from 240 KB to as much as 800 or 900 KB.

So simply looking at just the max number of files or the file size isn't necessarily giving you the whole story. What you should look for is fluctuation - either the number of files in the package going up and down, or the total package size going up and down. The key here being "down". In other words, if either the number of files or package size goes down on occasion, then you're probably OK and system is "auto-coalescing".

Another thing you can do is inspect the names of the files inside the package. Each file name begins with a GMT timestamp. If the names are different over a period of days, then old transactions are likely getting "smooshed" and new ones created as you make changes to your data.

-Dennis

[Toadling]

Originally Posted by Brian

No: only run the fix if sync slows down on the phone, or if you see files on the sync server that are older than the least recent sync you did on one of your devices.

Brian, on my system, it seems there's a delay in the coalescing. After all clients (one iPhone and one Mac) are synced, it seems to take several hours before the transaction files are coalesced. I haven't been able to pinpoint an exact delay, but it seems to regularly happen within 6-12 hours. I see this behavior on both my Mac database and on the sync server.

Because this happens consistently, I had assumed it was normal. But judging from your response above, I'm beginning to wonder if it shouldn't be happening immediately. Can you clarify?

BTW, I threw together a simple Automator app to do an inventory of my local OmniFocus database package. It simply runs "ls" and "du" shell commands on the package contents and writes them to a timestamped file. I run it periodically over a couple days and then compare the files with BBEdit's Find Differences command (although you could diff them any way you like, including by eyeball). Drop the app on Automator to make your own adjustments or just run it by double-clicking.

Download: Inventory OFDB

-Dennis