[English]Microsoft hat einen Speicherfehler in Microsoft Word bestätigt, der dazu führt, dass bestimmte Dokumentdateien ungewollt gelöscht werden. Die Entwickler untersuchen den Bug.
Anzeige
Worum geht es beim Word-Löschproblem?
Ich hatte das Thema am 2. Oktober 2024 im Blog-Beitrag Löscht Microsoft Word RTF-Dateien (auch .DOCX) wegen Großschreibung? nach einem Leserhinweis aufgegriffen. Es stand der Verdacht im Raum, dass beim Beenden von Microsoft Word Dokumente gelöscht werden. Dazu müssen folgende Bedingungen erfüllt sein:
- Dazu muss das Word-Dokument bearbeitet worden sein, und Word wird beendet, bevor die Änderungen gespeichert werden. Und der Benutzer bestätigt, dass die Datei gespeichert werden soll.
- Enthält die Datei das Zeichen # im Dateinamen oder einen Großbuchstaben in der Dateinamenerweiterung.
Treffen die Bedingungen zu, wird die Dokumentdatei in den Papierkorb verschoben. In den Kommentaren zu obigem Beitrag bestätigen Blog-Leser, dass der Fehler in Microsoft Word 365 (Current Channel) reproduziert werden kann.
Microsoft untersucht das Problem
Das ging rasend schnell: Ich hatte das Problem im Microsoft Answers-Forum hier auf Deutsch und hier auf Englisch gepostet. Zudem hatte ich einen entsprechenden Hinweis im Microsoft Answers-Forum Thread Kritischer Bug – Word löscht Dateien nach dem Speichern wenn diese ein # Zeichen im Dateinamen haben aus lokalen Laufwerken und Laufwerken im Netz gepostet.
MVP-Kollegin Lisa Wilke-Thissen hat sich dann des Themas angenommen, Bestätigungen von Kollegen eingeholt und das Problem an die Microsoft Produktgruppe gemeldet. Kurze Zeit später wurde dann ein Trick bekannt, wie das Verhalten temporär verhindert werden kann.
Anzeige
Das Problem taucht in Microsoft Word 365 nicht mehr auf, wenn unter Datei – Optionen – Speichern die Option Backstage beim Öffnen oder Speichern von Dateien … markiert wird.
Keine Ahnung, warum das so ist. Unabhängig davon hat Microsoft zum 3. Oktober 2024 den Support-Beitrag Locally saved Word files with capitalized file extensions or # in the title may be deleted after save veröffentlicht.
Dort wird bestätigt, dass in Microsoft 365 in der Version 2409das Problem auftreten kann, dass einen Datei nach dem Speichern gelöscht wird, wenn der Dateiname eine großgeschriebene Dateierweiterung (.DOCX, .RTF) oder das Zeichen # enthält. Das Problem tritt auf, nachdem die Datei bearbeitet und gespeichert wurde, wenn sie nach dem Schließen von Word dazu aufgefordert wird. Das entspricht exakt der Fehlerbeschreibung aus meinem obigen Blog-Beitrag und bezieht sich auf Microsoft Word 365. Das Word-Team bestätigt, dass man dieses Problem untersucht.
Mehrere Abhilfen möglich
Falls einem das Malheur passiert ist, kann man das ungewollt gelöschte Dokument aus dem Papierkorb zurückholen. Zudem wird eine Datei nicht gelöscht, wenn die Änderungen gespeichert werden, bevor der Nutzer Word 365 beendet. Oder man setzt die oben beschriebene Option Backstage beim Öffnen oder Speichern von Dateien …
Anzeige
… auf die root-cause-analysis von MS bin ich gespannt, ob es die jemals geben wird?. Ohne GB und User "held" [Grüße!] hätten wohl tausende User noch Wochen gerätselt oder verschwundene Files [Compliance voll betroffen, wie soll man auf solch defizitärer Basis ein Audit aufbauen, einfach die fertigen Audit-PDF-Testate auf Azure downloaden?] einfach akzeptiert.
… und wieder geht MS den schmalen Grad zwischen "Endkunde ist Betatester" und "wir sind verantwortlich und haftbar – aber besser – ne, wohl nicht.". Frei nach Fefe: Softwareproblem wie in DE oder Helsinki am Flughafen – kann man nix machen, tja.
naja die meisten hätten es doch gar nicht erst bemerkt…
betrifft ja nur die aktuelle Branch und dann muss nen # im Namen sein oder der Dateityp mind. einen Großbuchstaben enthalten… Wie oft kommt das bei euch vor?
Ich habe hier keine einzige Datei auf die das zutrifft, um das zu testen musste ich extra so eine erstellen und dann ist meine Officeversion 2021LTSC Professional Plus nichtmal betroffen auch die alten 2019 2016 und die 2024LTSC Professional Plus nicht… nur aktuelle Office 365 version 24ox
Ich gehe ja immer noch davon aus da Office 365 die einzigen mit KI ist das da was querschiesst. So nach dem Motto Namensgebung entspricht nicht den zulässigen Definitionsregeln muss phöse sein, also weg damit.
# im Dateinamen kommt sicher nicht oft vor. Da hast du vermutlich Recht. Aber einen Großbuchstaben in der Dateierweiterung finde ich jetzt nicht so ungewöhnlich.
Wobei…. ich habe tatsächlich auch kein einziges Word oder Excel Dokument mit Großbuchstaben in der Dateierweiterung bei mir gefunden
Der Gartenzaun bedeutet ja auch "Nummer", ich kann mir schon vorstellen, dass das benutzt wird, um z.B. verschiedene Teile / Kapitel als Einzeldateien voneinander zu unterscheiden.
Im dritten Microsoft-Answers-Artikel schreibt der User Hans Graßl:
"Das Problem tritt NICHT auf OneDrive auf."
Nur lokale Laufwerke und Netzlaufwerke sind betroffen.
Da kann man auch böswilliges Nudging seitens Microsoft unterstellen, um die Kunden endlich in die Cloud zu zwingen, damit man die Daten optimal klauen kann.
So ein "Fehler" passt nämlich voll zu deren Agenda.
Warum sollte man gutwillig Inkompetenz unterstellen nachdem die "Sicherheit first"-Vorgabe von höchster Stelle proklamiert wurde?
Wäre es Inkompetenz, dann würde die Änderung evtl. nicht gespeichert oder der Dateiinhalt auf Null gesetzt, aber die Datei wäre noch vorhanden.
Für die Verschiebung in den Papierkorb braucht es eine zusätzliche Löschfunktion, die in Office aber normalerweise gar nicht enthalten ist. Eine SAVE-Routine kann nicht in den Papierkorb verschieben.
Word bieten drei Optionen an:
1. speichern
2. nicht speichern
3. Abbrechen
Eine 4.Option LÖSCHEN habe ich in Office noch nie gesehen, also kann das auch nicht versehentlich aktiviert worden sein.
Löschen geht normalerweise nur im Datei-Explorer des Betriebssystems, aber nicht direkt mit einer Office-Funktion.
Bei SAVE eine LÖSCHfunktion aktivieren und dann auch noch in Abhängigkeit der Zeichen "#" im Dateinamen oder Großbuchstaben in der Dateierweiterung, aber NICHT, wenn diese "Backstage-Option angehakt ist und NICHT, wenn die Datei auf Onedrive liegt?
Das ist abstrus.
Man sollte Microsoft verklagen, damit sie dann vor Gericht im Debugger beweisen, wie der Programmablauf ist, der zu so einem Fehlerbild führt.
Ein Bugfix reicht da nicht. Man braucht eine technische Erklärung, was da passiert. Sonst muss man Microsoft das Vertrauen entziehen und konsequent sämtliche Produkte von denen rauswerfen, damit Microsoft garantiert keine Dateien mehr löschen kann.
Ich glaube jetzt eher, dass der Fehler auf OneDrive nicht auftritt, weil dort doch sicher das speichern anders funktioniert (ist ja ein sharepoint). Deine Unterstellung scheint mir schon etwas weit hergeholt zu sein.
Ich möchte MS da keine Absicht unterstellen.
Die temporäre ~$Dateiname wird ja auch irgendwie gelöscht.
Mann kann allerdings schon auf schräge Gedanken kommen, wenn man sich mal den Dialog genau durchliest:
https://administrator.de/knowledge/microsoft-365-word-loescht-ungefragt-dateien-current-channel-668585.html
Da steht wortwörtlich im Screenshot des Speicherdialog von Microsoft Office 16.0.18025.20104:
"Vermeiden Sie in Zukunft den Verlust von Änderungen an dieser Datei, indem Sie sie stattdessen in einem in der Cloud gesicherten Ordner speichern."
Ich finde, dieses Indiz stützt meine These des böswilligen Nudging.
Sie haben da aber eine schöne Datei. Wäre doch schade, wenn der etwas passieren würde.
Schutzgelderpressung.
Die temporären Dateien werden aber nicht in den Papierkorb gelöscht, sondern verschwinden restlos. Damit dürfte es also nicht zusammenhängen.
ok dann nutzt dafür eine Namensgebung /Dateityp erweiterung welche in wieviel Promille der Fälle auftretten?
Das ist dann doch eher Aluhut Logik.
Test für den Rollout des Bugs der in Zukunft dann mehr Namensgebung /Dateitypen trifft?
Naja, so ein (dummer?) Fehler hat nicht wirklich was mit IT-Sicherheit zu tun. Das fällt eher unter die Jack-Tramiel-Kategorie "It's not a bug, it's a feature".
"Nur lokale Laufwerke und Netzlaufwerke" … "Nur Netzlaufwerke" – das ist natürlich dumm, schonmal ein Netzlaufwerk mit Papierkorb gesehen? Ich nicht…
"Für die Verschiebung in den Papierkorb braucht es eine zusätzliche Löschfunktion, " – auf die Auflösung, wie es zu dem Problem kam, bin ich auch gespannt. Vielleicht ein falsch berechneter Funktionsaufruf, der aus einem "Write" ein "Delete" macht? Und der Delete-Befehl in Windows verschiebt erstmal in den Papierkorb, sofern vorhanden (Wechseldatenträger und Netzlaufwerke haben keinen).
"Man sollte Microsoft verklagen," Ja, mach mal. Verklag mal jeden Softwarehersteller für seine Programmfehler. Immer nur dieses "Sollte", "Müsste", … Machen. Thunderbird hatte vor vielen Jahren mal einen Bug, der dazu führte, dass alle von einem Outlook-Client versandten Emails, die von Thunderbird empfangen wurden, nach ein paar Monaten spurlos gelöscht wurden, verklag doch mal Mozilla dafür, ich hab damals viele Mails verloren…
Das "Löschen" von Dateien erfolgt i.d.R. durch das "Umbenennen" der Datei in der Verzeichnis Struktur. Darum funktioniert das nur auf dem lokalen Laufwerk, auf dem sich der Papierkorb befindet. Es kann lokal auch ein Hardlink vom Papierkorb aus gesetzt werden, so dass auch funktioniert, wenn der Papierkorb nicht auf dem gleichen Laufwerk liegt
Darum hat Ondrive das Problem nicht.
Es gibt keinen Papierkorb und auch keine Hardlinks.
Dieses Umbenennen hat den Vorteil, das es "monolithisch" ist. Würde eine zu löschende Datei erst in den Papierkorb kopiert und dann erst gelöscht, könnte der Löschvorgang gestört werden.
Auch dauert das Umkopieren eine deutlich längere Zeit als das Ändern eines Verzeichnis eintrages. Auch möchte man keine 2 gleichen Dateiinhalte haben.
Das Wegmoven hatte das Risiko,das es fehlschlägt, wenn es das Ziel schon gibt.
Eigentlich sollte das Grundwissen sein.
Was lehrt MS eigentlich auf den schweineteuerrn Kursen in 5-*-Hotels?
Oder vielleicht auf dem Gymnasium oder Studium oder on der Praxis?
das ist das Problem mit Scheininnovationen bei den Abo Produkten: wenn man so viel zahlt, erwarten die Kunden scheinbar permanent Neuerungen.
Dieses mal gab es eine unerwünschte Dreingabe, so ein Pech aber auch.
Was spricht gegen eine funktionierende Office Version die 5 Jahre und mehr (früher 10 Jahre max.) einfach ihren Dienst verrichtet?
Steigt die Produktivität an, wenn man Office 365 einsetzt? Der ifo Index zeigt aktuell was anderes;-)
Vielleicht ist ja unser Niedergang nicht die Folge der hohen Energiepreise, sondern wegen des Cloud-Hypes?
Unter der Winfuture-Meldung hat jemand geschrieben, dass auch Word 2016 betroffen ist.
Außerdem, bei Netzlaufwerken und Wechseldatenträger gibts keinen Papierkorb, da kann man nichts mehr zurück holen.
Volumenschattenkopie? Backup? Natürlich geht das ;)
als GPO habe ich diese Einstellung noch nicht gefunden.
was ist backstage zum teufel nochmal? wasfuer ne funktion, wasfuer konzept wasfuer api oder was genau?
just what the
Heise berichtet jetzt auch über den Bug:
www[.]heise[.]de/news/Microsoft-warnt-vor-Word-Fehler-Dateien-geloescht-statt-gespeichert-9964336.html
5 Tage später als hier im Blog.
Die Redaktion von Golem hat es zumindest geschafft, in deren Beitrag auf den Blog-Beitrag hier zu verlinken ;-).
Nennt sich der Bug künstliche Demenz und ist dies ein Wink (mit dem Zaunpfahl) für die MS-Cloud?
wir konnten die Fehler-Problematik übrigens per Gruppenrichtlinie bei mehreren Kunden durch Deaktivierung der "New Save Experience" (Humor haben sie…) für alle Onlinespeicher von Microsoft beheben: https://support.microsoft.com/en-us/topic/what-administrators-need-to-know-about-the-new-save-experience-in-office-c1f1a8a7-967b-45b3-a9df-910fbf93311f
Auf Deutsch hat die Einstellung je nach Alter der ADM/ADMX Templates teils unterschiedliche Namen.
Ungetestet, aber sollte auch klappen via Registry für Nutzer ohne Gruppenrichtlinien Verwaltung: https://www.heise.de/ratgeber/MS-Office-OneDrive-aus-Speichermenue-entfernen-9619015.html
Ich bin da übrigens auch der Meinung, dass das doch langsam kein Zufall mehr ist…
Schlimmer als den Fehler an sich finde ich wie Microsoft damit umgeht.
Es gibt keine andere Firma, die sich sowas leisten kann.
Die löschen eventuell Dateien ihrer Kunden und halten es nicht mal für nötig die Kundschaft darüber zu informieren. Das Problem ist ihnen seit 03.10. bekannt…
Ich lach´mich weg. Ich finde, M$ Office sorgt für guten Unterhaltungswert; da ist jeder Pfennig bestens investiert.
die 365 Update für heute sind online (Current und Enterprise Channel)
Moin
Fehler ist bei mir Korrigiert worden. @Günter
Fehler ist wohl mit dem Update von heute 08.10.2024 Korrigiert.
Update auf 16.0.18025.20140
Word zeigt aber immer noch "16.0.18025.20030" bei "Info zu Word" an. o.O
– Backstage ist Deaktiviert, wie gewohnt.
kein Automatischer Löschvorgang mit # im Namen oder Großbuchstaben in der Datenendung.
Am 8.10. Nachmittag das Update eingespielt und gleich getestet. Fehler noch da.
Am 9.10. nochmals getestet. Fehler weg.
Dazwischen war kein Update mehr für Office. Auch die Build ist gleich geblieben 18025.20140
Ich habe es im Blog-Beitrag Word-Bug-Fix: Dokumente mit # oder Großbuchstaben im Namen wurden gelöscht aufgegriffen.