Release Notes: "Edits made to embedded attachments in flat files will be saved."

So I just happened to glance at the release notes for the new test build

It says: Attachments — Edits made to embedded attachments in flat files will be saved.

Wow, is this correct? If so, fantastic job!!! I thought that OO had structural problems with being able to edit embedded files. For me, it has been the one sticking point that keeps me from using OO for more than just drafting text. There have been a number of threads about this issue and I assumed it would never get solved. So, two questions:

  1. Am I interpreting that correctly? Can I now embed a document, then click on it, edit it, save it, and my edits won’t later get trampled when I save the enclosing oo file?

  2. Did some previous update already make this work for package files and now it also works for flat files, or is it only doable for flat files right now?

Thanks for any information on this excellent (I hope) improvement.

Whenever I try this, I just get a message that says the file can not be edited and that a copy has been made. Any experts know what I might be doing wrong? Or maybe I’ve misunderstood the note in the release notes. Thanks for any insights.

Could you please tell me:

  • What specific build you’re using, the revision number is in the About OmniOutliner window next to version
  • What version of macOS
  • What kind of file attachment
  • What app you’re making edits to it with
  • What your order of making edits and saves to the attachment and OmniOutliner you’re taking.

In general editing embedded files in both flat and package files should work with 5.1.

Thanks very much for taking a look at this Derek.

Omnioutliner: 5.1 test (v181.17.2 r292498)
OS X 10.12.4 (16E195)
MacBook Pro (Retina, Mid 2012)

Steps to reproduce:

  1. Open blank-template OO file then save file
  2. type a line of text into oo file
  3. embed a one-line plain text file (created with textmate)
  4. save the oo file
  5. right-click embedded file and open in textmate
  6. edit the text file
  7. save the text file and exit
  8. save the oo file
  9. right-click embedded file and open in textmate. Edits made in step-6 are gone.

I’m currently doing this with a flat oo file, but saw the same thing with the package format. Something is flaky with embedded editing in general. It will work sometimes, but if you continue to open/edit/save the embedded file and then also edit/save the oo file, you will start to lose changes in the embedded file. The flakiness is clear if you just watch the “edited” notice from OSX on the top of the oo file window. Once you’ve made edits to that embedded file, you’ll keep seeing the notice say “edited” a second after you’ve hit save on the oo file even though you’ve made no changes to it. If you hit save again on the unchanged oo file, again the “edited” notice will reappear on window a second later. This is likely some interaction between how oo is handling the bookkeeping of the embedded file, and what OSX is doing with it’s autosave/versioning feature.

If this oo feature is incompatible with OSX’s autosave/versioning, I’m happy to drop that in favor of editable embedded docs in oo. I see the same behavior if I embed a pdf file and then make some edit like adding a text note.

Again, thanks for looking at this, and also to the other devs for keeping embedded-doc editing on “the list.” For some of us, this is very important.

Ah, so TextMate doesn’t use file coordination which is the problem. So depending on the timing of edits and saves, they can get ignored. You shouldn’t see this issue if you try with TextEdit or Pages or such. If you disable Versions support, it would likely improve things with at least the file package case.

Hi Derek,

Thank you for the quick reply. OK, I understand the issue. I do see the same problem editing pdf files with Preview. Since that’s part of OSX, I’m surprised that it doesn’t coordinate properly. In any case, when you say “disable Versions,” do you mean disable it for any external program that doesn’t play nicely, or disable it for OO? If I disable it for OO, will that take care of things for all external programs automatically?

Preview should work when editing an attachment saved to a file package. When using the flat format, Preview has a peculiar issue of not wanting to edit files in the temp directory. Since there’s no file path to an attachment in a flat file, we have to write out a copy to the temp folder that is then edited. Preview is the only app we’ve seen that will refuse to edit files in this location.

While we don’t recommend it, you can try disable autosaving/Versions for OmniOutliner and see what happens.

Hello Derek,
Thank you for your replies, and my apologies for the slow response. I find that this simply does not work as you describe it… which is frustrating for me since for my use case, editing attached docs is the killer feature.

I’m only using packages in what I describe below

The key point is this: If you edit an attachment (using textedit or preview or word) then the changes will stick only if those edits are made after any changes are made to the enclosing oo file, and then you close the oo file. If you make changes to the attached file, save it, and then make changes to the enclosing oo file, your changes to the attached file will be wiped out as soon as you save the oo file. I tested this numerous times with all sort of apps and file types. I guess one could always remember to save oo changes and then open the attachment for editing, and then save the attachment, and then close the oo doc and reopen it. But that’s pretty clunky… and if you forget, then all your edits to the attached doc will be wiped out.

To track this down, I tried watching the package contents in the finder preview and also the preview in the oo file. It appears that oo is hanging on to a temporary version of the attachment, but that when you edit the attachment, you are editing the one that’s stored inside the package. Then the next time you save the oo file, it drops the version it’s holding on top of the one that contains your edits.

I know you suggested turning off versioning. I’m happy to do that, but do you mean that I should turn it off for oo, or for the app editing the attachment? Or should it be on both? Also, it’s not clear that this is doable anymore (running Sierra). I’d appreciate hearing if others have been able to solidly turn it off.

Thank you again for your help.


Sorry for the delayed response. I’ve been looking into this when I’ve had time. Aside from the separate issues of editing with Preview and non-file coordination apps, there does appear to be some bugs we can investigate. We can also make some attempts to deal with non-file coordination apps, but it will be far from foolproof. From the testing I’ve done, you should be able to edit embedded attachments of file packages safely if you save the embedded file (close it to be extra safe) and then make edits to the OO document. If you try to make edits in OO while you have unsaved changed to the embedded document, bad things could happen. That said, I thought I was seeing better results when looking at this earlier so there could be other factors at work. Our focus right now is on getting OmniOutliner 3 for iOS finished but we will look into this when we can.

Thanks Again Derek. I find that the essential requirement not to have your embedded-doc edits trampled is to close the oo file first, then save changes to the embedded files. The key point is that the oo file seems to hold an unedited version of the edited embedded file. And as soon as you hit “save” in the oo file, it’ll overwrite the embedded file removing your edits. I do have versions turned off both in oo and in all other apps I’ve been testing with.

A workable (albeit kludgey) workflow is:

  1. Open oo package file containing embedded files
  2. Make edits to both embedded files and the oo file freely
  3. do NOT close any embedded files that you have edited during the session
  4. When finished, save and close the oo file (this will trample any edits you’ve made to embedded files). However, since you still have the embedded files open in their corresponding apps, you’re safe.
  5. Save your embedded files (you’ll get a warning from the app that you’re overwriting existing versions). Ignore the warning and save them anyway
  6. Close embedded files.

When you reopen the oo file, all of your edits will be there.

The funny thing about this bug is that it should be repairable by just telling oo to stop writing out the embedded files when you save the oo file. The edits to the embedded files are always saved when you hit save in whatever app you’re working in. (I verified this by watching the contents of the package file.) So I don’t see why oo needs to write them out at all. Everything would be fine if oo just stopped writing out the embedded files when you save the oo file.