devonthink can't see inside new OmniOutliner files

Omni is releasing version 5 of omnioutliner (still in beta) and they have changed the file format. I noticed today that devonthink is no longer able to find words inside the file when doing a search. This might not be surprising, since it is a new format except that spotlight (and Alfred as well) search within the new format w/o any trouble. Omni tends to use pretty open formats, so I’d be surprised if it’s something they’re doing (esp since spotlight sees inside the files).

Any ideas?


You’re expecting DEVONthink to work with an unreleased beta product?

Anyway – DEVONthink is merely coming along for the ride. If you are using two versions of the same app on the same user account you’re also likely to get issues. Again – OmniGroup’s problem to fix.

Thank you for your quick reply. I understand your point about it being beta, but since things like spotlight and alfred, neither of which likely even know about omni’s existence, work well, I was wondering if there’s something else I should be doing. I tried a couple other things as well, and everything seems to see inside the files w/o problems except for devonthink. Good advice though about having both the release version and the beta version under the same account. Perhaps that somehow causes confusion for devonthink but not for other apps. I’ll try removing one.

One clue is that devonthink misidentifies the file type as XML, while outside of devonthink it is correctly identified as an “OmniOutliner Document.” Given that finder identifies it correctly, it’s not clear (at least to me) that the problem is OmniGroup’s mistake, as the type seems to be registered correctly.

OmniOutliner “files” are packages – special folders that OS X treats as if they were files. You can look inside a OmniOutliner package by command-clicking it and choosing “Show Package Contents” from the contextual menu. There are several files inside the OO package – the .xml file inside the package is where your data are stored. DEVONthink gets its information about files/packages, and file preview, from OS X.

Thanks for the reply. I usually just use the terminal to look inside them, as they are just directories in the filesystem. But both the old and the new Omni format had a fairly simple xml file called “contents.xml” in the directory/package that held the file proper. And then other directories for attachments etc.

Omni actually didn’t change much in the contents themselves. In both the old and the new format there’s a single contents.xml file. To see if they made subtle changes, I saved the same Omni file in both old and new format then just did a unix diff on the two contents files:

diff Untitled2.oo3/contents.xml Untitled2.ooutline/contents.xml .

The diff command showed there were some changes to key names, but not wholesale differences.

As a test, I saved a file in the new format and then changed the extension from ooutline (the new extension) to oo3 (the old extension). Then devonthink correctly found text within the file. I also tried stuffing the contents.xml file from the oo3 package to the ooutline package, and now devonthink couldn’t find text in the file (good that this isn’t biology as there’d surely be ethical concerns with that kind of genetic tinkering :slight_smile: ). So it seems that it’s really just the extension that’s causing the problems. I’d guess that devonthink believes that the new format is a pure xml file, but since the package is not simply an xml file it fails to search it properly.

So the question is: how does one tell devonthink to pick up the extension information that OSX and the finder already have registered?

If it’s OmniGroup’s problem, then perhaps they have a bug in their contents.plist file. But I’d think that’d mess up others apps that tried to search the file.

DEVONthink includes workarounds for OmniOutliner packages but doesn’t support the new extension yet.

OK, I see. Thanks very much for clarifying. Being able to see inside those files is a great feature of dtpo, and is much appreciated.

I just updated DTPO this afternoon. The release notes said that the new version is compatible with Omni’s new ooutline filetype. Thanks for getting to this issue so quickly. I just tested it and found the following:

  1. If I ask DTPO to open a .ooutline file with the external app, it correctly opens it with Omnioutline.

  2. The internal preview pane in DTPO just shows the file as garbled. It looks like it’s interpreting it as binary (not sure about that).

  3. DTPO will not find a word inside the ooutline file.

Again, thank you for working on this. It’s a very helpful feature of DTPO to be able to read those omni files!

Dear experts,

Does anyone know how to make DTPO look inside the new omnioutliner files? A DTPO version from a month or two ago said that the problem had been fixed, but I still find that DTPO can’t read the new OO files. I’ve tried saving the OO files as both flat files and as packages, but no joy either way. Perhaps I’m just doing something foolish. Any help would be greatly appreciated.


From OmniGroup’s release notes for OmniOutliner 5:

If OmniGroup cannot fix it, no one else can. You’ll just have to wait until the developer fixes the problem, I suppose.

If previews for your .oo3 files are not appearing, then uninstall v5, reboot, and reinstall v4.

Thank you for the quick reply. I should have been clearer in my question. When I say “look,” I don’t mean the “quick look,” I mean that DTPO is no longer processing the contents of oo files.

Try the following:

  1. Add the word “octopus” to an oo file
  2. import that file into DTPO
  3. Do a search within DTPO for the word “octopus”
  4. DTPO will not find any files that contain “octopus”

This happens whether you save the oo file as a package or a flat file.

With the old oo file format DTPO was able to look inside (i.e. process/search) oo files.

Thank you.