Warum in eine Notiz eingebettete Dokumente in der zugehörigen Anwendung nur schreibgeschützt geöffnet werden – außer in OneNote 2013/2016 für Windows.
Ein Doppelklick auf eine in OneNote eingebettete DOC-Datei öffnet diese in Word, wo man sie bearbeiten und wieder speichern kann – aber nur in OneNote 2016. In allen anderen Versionen wird das Dokument schreibgeschützt geladen und lässt sich nicht wieder zurückspeichern.
Die wichtigste und unangenehme Information vorab: Das ist systembedingt und lässt sich auch nicht mit irgendeiner Einstellung beheben. Zum Bearbeiten von Dateien, die an eine Notizseite angehängt, bzw. eingebettet sind, bleibt in OneNote für Windows 10 (UWP), iOS, MacOS und Android nur dieser umständliche Weg:
- Öffnen per Doppelklick und laden in die zugehörige Anwendung (z.B. Word für DOC/DOCX).
- Dort Speichern des Dokuments unter demselben oder einem anderen Namen in ein beliebiges Verzeichnis. Das aktuell bearbeitete Dokument nimmt bei den meisten Anwendungen automatisch den neuen Namen an.
- Bearbeiten und Ändern nach Bedarf.
- Speichern der Änderungen (immer noch unter dem neuen Namen im gewählten Verzeichnis).
- In OneNote die alte Version der angehängten Datei löschen
- Einfügen der neuen, geänderten Datei aus dem zuvor gewählten Verzeichnis.
Dabei ist dasselbe Problem zu beachten wie es auch bei OneNote 2016 (das diesen umständlichen Weg nicht braucht) existiert: Haben mehrere Nutzer (oder Sie selbst auf mehreren Geräten) dasselbe Notizbuch geöffnet, in dem sich auch die angehängte Datei befindet, gibt es eigenständige Versionen dieser Datei in den jeweiligen Cache-Ordnern. Mehr oder weniger gleichzeitig vorgenommene Änderungen werden also nicht zusammengeführt, sondern führen zu Dubletten und/oder Sync-Fehlern (siehe auch dieser Beitrag).
Warum das so ist
Wenn Sie sich fragen, warum die OneNote-Entwickler diesen offensichtlichen Bug nicht beheben, wenn es doch bei OneNote 2013/2016 für Windows auch geht: Es ist kein Bug, sondern eine Einschränkung des jeweiligen Betriebssystems (bzw. im Fall der Windows 10 App der UWP-Architektur).
Unter Windows gibt es historisch bedingt keine Verzeichnisse, die nur einer bestimmten Anwendung „gehören“. Zwar existieren diverse Systemordner, teils auch versteckt, in die Programme nur schreiben dürfen, wenn der Nutzer mit Administratorrechten angemeldet ist. Auch gibt es zwar spezielle Anwendungsordner, in denen Programme z.B. ihre Einstellungen ablegen. In die darf aber theoretisch auch jede andere Anwendung schreiben. Ein solcher Anwendungsorder ist auch der OneNote-Cache (von OneNote 2016). Und genau hier landen alle Inhalte geöffneter Notizbücher, auch eventuell angehängte Dateien. Word für Windows darf eine darin von OneNote aus geöffnete und geänderte Datei ohne weiteres wieder dorthin zurückschreiben.
Unter anderen Systemen wie MacOS, iOS oder Android ist das anders. Dort hat jede Anwendung oder App ihr ganz eigenes Verzeichnis, in dem nur sie selbst Schreibrechte hat. Das gilt auch für OneNote. Bei MacOS oder Android gibt es zusätzlich allgemein zugängliche Ordner für Dateien und Userdaten. Bei iOS gilt das meines Wissens nach nur für die Bilderordner – hier liegen auch die Anwendungsdaten im App-eigenen Verzeichnis. OneNote braucht auch auf diesen Systemen einen Cache-Ordner, in dem es geöffnete Notizbuchinhalte zwischenspeichert, ist hier aber alleine schreibberechtigt. An eine andere App (z.B. Word) übergebene Daten darf diese zwar lesen, aber nicht in den OneNote-eigenen Systemordner (Cache) zurückschreiben. Deshalb der Read-Only-Zugriff und der eingangs gezeigte notwendige Workaround.
Die OneNote-App für Windows 10 läuft zwar unter Windows und sollte daher eigentlich keiner solchen Einschränkung unterliegen. Jedoch hat Microsoft die Architektur speziell von UWP-Apps so gestaltet, dass sie – ganz ähnlich wie bei MacOS und den anderen Systemen – ebenfalls nicht in die Verzeichnisse anderer Apps schreiben dürfen. Deswegen passiert hier genau dasselbe.
Bei einer Rückfrage beim OneNote-Produktmanager erklärte mir dieser, dass man sich des Problems durchaus bewusst sein und es auch gerne beheben würde. Bislang ist aber wohl keine Lösung in Sicht.
Damit ist doch das Konzept der embedded files gescheitert. Sollte zwar das Arbeiten in der Cloud erleichtern (deshalb hatte man ja die Möglichkeit von Links auf insbesondere lokale Dateien beim Drag&Drop entfernt).
Bringt aber nur Ärger. Wie Du ja selbst schreibt klappt die konkurriernde Bearbeitung nicht. Zudem muss bei jeder Änderung die komplette Datei nach OneDrive übertragen werden. Und Suchen in diesen Dateien geht auch nicht.
Bernd
Seh ich ein bisschen anders. Das „Konzept der embedded files“ ist dann gescheitert, wenn OneNote von vorneherein als Dokumentenverwaltung angelegt gewesen wäre. Also etwas zum gemeinsamen Bearbeiten und Verschlagworten von Originalfiles. Das ist es m.E. nie gewesen, auch wenn manche versuchen, es dazu zu missbrauchen. Es war immer nur ein „Notizprogramm“, in dem ich eben auch Bilder, Links oder Dateien als „starres Archiv“ speichern kann. Alleine schon die Tatsache, dass eingebettete Dokumente als eigenständige Kopie in einem temporären Ordner „leben“ (nicht anders als bei einem Mail-Programm wie Outlook) widerspricht ja schon dem Dok-Management.
Und die beschriebene Einschränkung kommt nun mal von den Betriebssystemen (für die OneNote anfangs nie vorgesehen war, die es teilweise nicht einmal gab).
Wenn ich MSFT hier was vorwefen kann, dann dies: Warum haben Sie nicht die Option, Dokumente einzubetten oder von OneNote aus zu öffnen, bei MacOS und Co. gleich ganz weggelassen?
Weil der Shitstorm vermutlich weit größer geworden wäre als mit diesem „Schönheitsfehler“.
btw: Das Konzept der Stifteingabe ist in OneNote auch nicht gescheitert, nur weil das Programm nicht die Möglichkeiten anderer Zeichenprogramme bietet. Es ist ein Notizprogramm.