OneNote Always Opens Attached Documents as Read-Only

Documents that are embedded in a OneNote page will always open in read-only mode. The only exception is OneNote 2013/2016 for Windows. An explanation.

Double-clicking on a DOC file embedded in OneNote opens it in Word, where you can edit and save it again – at least it seems to be supposed this way. But this only in works OneNote 2016. In all other versions, the document is opened as Read-Only and cannot be edited and saved back to OneNote.

The most important and unpleasant information beforehand: This is system-related and cannot be corrected by any setting. This affects OneNote for Windows 10 (UWP), iOS, MacOS and Android. All these versions only allow you to edit a file that is embedded in a OneNote page using an inconvenient workaround:

• Open the file in its corresponding application (e. g. Word for DOC/DOCX) by double-clicking.
• From there save the document under the same or a different name in any directory. The edited document usually automatically adopts the new name.
• Edit as required.
• Save the changes (still under the new name in the selected directory).
• Delete the old version of the attached file from the OneNote page.
• Manually insert the new, modified file from the previously selected directory.

Note: No matter, if you have to use this method or not (as you are using OneNote 2016 for Windows), one problem remains and has to be considered: If several users (or you yourself on several devices) have opened the same notebook that contains the attached file, there are separate versions of this file in the respective cache folders. Changes made at about the same time (or before having been completely synchronized from other devices) are not merged automatically. Instead, they usually lead to duplicates and/or sync errors. That’s because OneNote only allows concurrent edits on different objects (which may even be on the same page). Objects are text paragraphs, images and embedded files.

Why?

This seems to be a bug in the respective OneNote versions because it obviously works well in OneNote 2016 for Windows. So why don’t they fix it? Because it’s not a bug, but a restriction of the respective operating system (or the UWP architecture in the case of the Windows 10 app).

Under Windows, for historical reasons, there are no file directories that are exclusive to one particular application. There are various system folders, some of them hidden, into which programs can only write if the user is logged in with administrator rights. There are also special application folders where programs store their settings, for example. In theory, however, any other application may also write into it. The OneNote cache (from OneNote 2016) is one of those application folders. And this is exactly where all the contents of open notebooks, including any attached files, end up. Word for Windows is allowed to write a file that has been opened and changed from within OneNote back to that cache folder without any restrictions.

This is different in other systems like MacOS, iOS or Android. On those, each application or app has its own directory where it has exclusive write access. This also applies to OneNote. OneNote needs a cache folder on these systems as well, in which it keeps open notebook contents. And only OneNote is allowed write access here, while other applications, like Word, may only read data (or get them transferred). There is no way though, that Word (or other applications) could write changed content back to that cache folder. That is what makes the read-only restriction and the described workaround necessary.

Now one should think that at least The OneNote app for Windows 10 runs under Windows and should therefore not be subject to such restrictions. However, Microsoft has designed the architecture of UWP apps in such a way that they are not allowed to write in the directories of other apps – similar to MacOS and the other systems. That’s why exactly the same thing is happening here.

When I talked about it to OneNote product manager, he said, that the developers are aware of the problem and would be happy to fix it somehow. However, so far no solution is in sight.