[Tate]

Hi,

I just worked for 30 minutes typing tasks in to the the newest sneaky peek version of OmniFocus and it decided to crash. When it re-opened and reverted to the database none of that work was there. Big bummer. I understand this is a crash and that is what happens, but how can I save my information constantly while I'm using these sneaky peeks so that this doesn't happen to me again?


I keep just wanting to hit command-s for save.


Should I be using the, "back up database" command? (Does that really mean back up TO database since back up database sounds more like copying the database file that already exists.) Wouldn't it make sense just to have a control-s command that saves to the database file (don't see one). I don't have a sync to server situation yet, but I need a very quick keystroke method of saving all my information so that I know if the application crashes it will be there when I re-start. Waiting to back-up until I quit doesn't help me in a crash situation.


Thanks,
Tate.

[whpalmer4]

If you configure the sync code to sync to a file on your disk, you should get a "backup" automatically about 1 minute after you make a change. I'm at a loss to explain how you lost half an hour of work, however, as I see OmniFocus write changes out to the database on disk immediately. That sounds like a bug that ought to be investigated; perhaps the Omni engineers can figure out what happened if you provide them with a copy of your database before it gets changed, along with your console log and the crash report.

[Tate]

Never happened like this to me before. I'm also not sure what happened, but after the crash it looked like the original db I opened up this morning.

I guess I'm just looking for a better way to know that my information is in sync with the current back-up besides quitting the application.

[Brian]

I'm really sorry this happened! OmniFocus actually writes out changes continually as you make them; the reason there isn't a save command is because we're basically always saving. As you leave a row and select another, any changes you made are being written out to disk. The intent is for the functionality to resemble the way iTunes works.

Obviously, the changes appear to not have made it to disk in this case. There's one bug we used to have which would produce results like this, but we added a workaround and haven't heard about it again in several months. The undo stack stops notifying us of changes, so data stops getting saved to disk.

When this crash happened, did OmniCrashCatcher come up, and if so, did the crash report get sent in? I tried searching for crash reports from the same email address that your forum account uses, but didn't find any. If there's another email address you may have used, can you send me a private message with that info?

I ask because we added code to detect when the app might be getting into a bad state - when that code goes off, we force the app to crash before you can do work that won't get recorded to disk. So if this is the same bug, we should have crashed earlier in your work session.

If I can take a look at your crash report, I'll be able to tell whether we need to detect the bad state differently/earlier, or whether there's a separate problem hidden in there that we need to figure out from scratch.

That all said, the situation you ran into appears to be very rare - this is the first time in several months that I can remember encountering a case like this.

[Tate]

Hey Brian,

Thanks for the condolences, but fortunately it was nothing catastrophic - just a little lost time/work on a busy morning.

Indeed, there was another email address, which I have sent you in a privatre message, where a crash report was sent from. Hopefully, this will give you a clue.

Thanks