[English]Kurze Frage an die Leserschaft des Blogs: Ich habe gerade die Information erhalten, dass Microsoft Word seit dem heutigen 2. Oktober 2024 RTF-Dateien löscht, sobald die Dateinamenerweiterung .RTF in Großbuchstaben geschrieben wird. Ergänzung: Inzwischen sind mehrere Bestätigungen eingetroffen – ein Großbuchstabe in der Dateinamenerweiterung oder ein # im Namen reicht zum Löschen.
Anzeige
Ein Leserhinweis
Blog-Leser held hat sich im Diskussionsbereich mit einem Kommentar gemeldet, dessen Inhalt ich mal hier in den Blog-Beitrag ziehe. Der Leser ist in seiner Umgebung auf ein Problem gestoßen, das zum Verlust von Dokumenten führen kann.
Problem scheinen wohl groß geschriebene Dateiendungen zu sein, die Microsoft Word nicht mag und dann einfach die betreffenden Dokumentdateien löscht. Der Leser schreibt unter dem Begriff "gefährliches Word Problem mit großgeschriebenen Dateiendungen", dass der Effekt seit "heute" auftritt und er dass er das Verhalten mit folgenden Schritten reproduzieren kann.
- Ein Word-Dokument mit WINWORD.EXE /T C:\test.RTF anlegen lassen
- Dann diese neue Datei verändern, damit das Dokument neu geschrieben wird.
- Word über die Schließen-Schaltfläche beenden und das Dokument dabei speichern .
Eigentlich sollte dann auf dem Laufwerk C:\ die Datei test.RTF zu finden sein. Aber laut Leser wurde dieses Dokument durch Microsoft von der Festplatte gelöscht. Grund sei die Großschreibung der Dateiendung RTF.
Anmerkung: Es ist egal, wo die Datei abgelegt wird, wie held in einem der nachfolgenden Kommentare schreibt. Wichtig ist lediglich, dass Word bei einem geänderten Dokument geschlossen und dann die Speicherung bestätigt wird. Wird in Word erst gespeichert und dann das Programm beendet, tritt der Fehler nicht auf.
Anzeige
Der Leser merkt an, dass so ein Vorgehen evtl. von Dokumentmanagement-Systemen (DMS) verwendet wird. Hier können massenhaft Dateien verloren gehen. Auf Facebook habe ich die Rückmeldung eines Administrators bekommen, der genau dies bei einem Kunden beobachtete.
Lässt sich das Problem nachvollziehen?
Leider hat der Leser in seinem Kommentar keine Information zur verwendeten Word-Version und zum eingesetzten Windows hinterlassen. Daher die Frage an die Leserschaft: Kann dieser Effekt von euch nachvollzogen werden?
Oder ist das Einzelfall und durch die Umgebung des Lesers verursacht? Bei einer kurzen Suche im Web konnte ich bisher keinerlei Berichte zu diesem Bug finden.
Ergänzung: Ein Leser hat mir obigen Screenshot mit einer Meldung geschickt, wo die fehlende Datei test.RTF bemängelt wird. Es haben sich ja einige Leser gemeldet, die das Verhalten nachstellen können. Um Diskussionen, dass auf das Systemlaufwerk C:\ gespeichert wird, zu vermeiden, legt die Word-RTF-Datei im Profilordner Dokumente an und prüft, ob diese ebenfalls gelöscht wird.
Ergänzung 2: Ein Leser hat mir auf Facebook folgendes bestätigt: Er hat heute auch bei einem Kunden dieses Erlebnis gehabt. Aber dort ging es nicht um .rtf-Dokumente, sondern um das .docx-Format. Aussage war: "*.docx bleibt, *.DOCX wird gelöscht".
Das DMS beim Kunden speichert alle Dateien in Großbuchstaben.
Ergänzung 3: Auch das Zeichen # im Namen führt wohl dazu, dass Word die Dokumentdatei löscht, wie ich in diesem Microsoft-Answers-Beitrag gerade gelesen habe. Auf administrator.de hat jemand diesen Thread dazu eröffnet, nachdem er den Blog-Beitrag hier gelesen hatte. Dort sind noch einige Screenshots mit Meldungen zu sehen.
Stört eine Sicherheitsfunktion
Aktuell ist mir unklar, was dieses Verhalten verursacht – zumal in den nachfolgenden Kommentaren Leser das Verhalten nicht haben, während andere Nutzer genau das oben beschriebene Verhalten sehen.
Gibt es in Word eine entsprechende Schutzfunktion, die das Löschen veranlasst? Ich habe ewig kein aktuellen Office mehr in den Fingern gehabt und auch nichts dergleichen zum Testen installiert.
Denkbar wäre auch, dass der Defender in Windows mit seinem "Überwachte Ordner"-Schutz dazwischen geht und die Dateien löscht – wobei diese dann in Quarantäne geschoben werden müssten – und nicht, wie in nachfolgenden Kommentaren angegeben, im Papierkorb landen. Alles in allem ist es ein sehr seltsames Verhalten, was da über verschiedene Microsoft Word-Versionen beobachtet wird.
Die Lösung
Ich hatte das Problem im Microsoft Answers-Forum gepostet, wo es auch einen zweiten Thread Kritischer Bug – Word löscht Dateien nach dem Speichern wenn diese ein # Zeichen im Dateinamen haben aus lokalen Laufwerken und Laufwerken im Netz gibt. Dort hat Lisa Wilke-Thissen die Ursache benannt.
Das Problem taucht in Microsoft Office auf, wenn unter Datei – Optionen – Speichern die Option Backstage beim Öffnen oder Speichern von Dateien … nicht aktiviert ist. Erklärt auch, warum manche Nutzer den Effekt nicht nachstellen können. Vielleicht mal prüfen, ob Betroffene damit weiter kommen.
Ergänzung: Microsoft untersucht nun den Fehler, siehe Microsoft untersucht Word-Bug, der Dateien beim Speichern löscht
Anzeige
Unter Windows 10 22H2 und Word 2019 bei mir nicht nachvollziehbar (habe allerdings Laufwerk D:\ verwendet, falls das relevant sein sollte).
Ja, es ist relevant. Denn in der Standardkonfiguration kann und darf ein Domänen-Benutzer auf "Laufwerk C" im root keine Dateien erstellen.
Diese Einschränkungen gibt es nicht auf anderen Laufwerken.
Genauer gesagt betrifft es das Laufwerk, auf dem Windows vorhanden ist.
Darum finde ich den "Bug" etwas merkwürdig. Wer bitte kommt auf die Idee im %SystemDrive% Dateien abzulegen?
—
@Günter
Auf Laufwerken, die normale Schreibberechtigungen haben, wird nichts mit ".RTF" seitens Windows gelöscht.
Und unter %SystemDrive% kann ich als Domänenbenutzer erst gar keine Dateien erstellen, was auch gut ist.
Mit administrativen Berechtigungen kann ich eine test.RTF reinkopieren, öffnen, editieren, beenden (und dabei speichern) – die Datei bleibt erhalten.
Hat da jemand an seinen Datei-Berechtigungen rumgefummelt?
Nein, hat er nicht.
C:\test.RTF war ein Beispiel um jegliche Komplexität rauszunehmen. Der Pfad spielt keine Rolle. Es sind auch Netzlaufwerke und andere Laufwerksbuchstaben mit sämtlichen Unterordnern betroffen.
Danke für die Ergänzung!
Office365, aktuellste Version, Release vom 25. Sept.
Reproduziert auf W10, W11, Server 2022
Eben getestet und kann nicht nachgestellt werden (O365 Version 2407 Build 16.0.17830.20210).
Abgesehen davon: /t öffnet eine vorhandene Datei und erstellt keine neue in diesem Sinne.
Da hab ich mich zu unklar ausgedrückt. Nimm bitte eine gegebene (entbehrliche) Datei und öffne sie per /t
bearbeite die Datei ohne zu speichern und klicke X
dann auf Nachfrage speichern
Datei ist weg, wenn beim Aufruf mit -t das RTF groß geschrieben wurde
Bei O365 ist wohl nur der Current Channel betroffen, sonst wär das bei uns schon früher aufgefallen.
Hatte ich genau so getestet, da ich ja angemerkt habe, dass mit /t nur eine Datei geöffnet wird :)
In dieser Version (Monthly Enterprise) besteht das Problem definitiv nicht. Also könntest du recht haben und ist damit leider wieder ein prima Beispiel dafür, warum man Produktivumgebungen nicht auf Current betreibt IMHO.
Und im "Standard" ist die Option aus der "Lösung" auch nicht aktiv. Aber das hast du gestern ja in einem anderen Kommentar schon klargestellt.
"The default update channel for Microsoft 365 Apps for enterprise and Microsoft 365 Apps for business is Current Channel."
Ich gebe dir aber recht. Wir werden das schleunigst überdenken.
Win 10 22H2 Build 19045.4957 / Office 2021 Professional Plus LTSC 2108 Build 4332.20771
nicht nachvollziehbar.
Test mit Win 11 23H2 22631.4169 / Word 2409 Build 18025.20104:
Neues Dokument, abgespeichert als Test.rtf
Rename der Datei in Test.RTF
Datei mit Word geöffnet, geändert, Schließen mit Speichern
Datei anschließend im Nirwana…
Hast du mal im Papierkorb des jeweiligen Nutzers nachgeschaut? Bei mir war die verschwundene Datei dort zu finden. Ansonsten waren meine Schritte mit deinen identisch.
Nachvollziehbar.
Word für Office 365, Version 2409, build 16.0.18025.20030 – 64 bit
windows 10, 22h2, build 19045.4957
* test.RTF auf dem Schreibtisch erzeugt
* mit Word geöffnet, modifiziert
* Word beendet, Speichern-Dialog bestätigt
=> Datei landet im Papierkorb (sie *scheint* also vom Schreibtisch zu verschwinden)
Passiert das auch, wenn du erst normal speicherst (Datei, speichern) und erst danach normal beendest (Datei, beenden)?
Update:
* Das Problem tritt bei mir nur auf, wenn man beim Beenden speichert. (Also: Word beenden wollen, ohne vorher gespeichert zu haben => word fragt nach Speicherung => Ja, bitte speichern => Datei wird in den Papierkorb verschoben)
* Das Problem tritt *nicht* auf, wenn man vor dem Beenden von Word per "Diskettensysmbol" manuell gespeichert hat
* Ich kann bestätigen: ein Großbuchstabe in der Endung ist ausreichend.
sollte aus obigem Text und den Kommentaren von held aber klar geworden sein.
Verhalten wie bei Dir. Landet im Papierkorb.
Ich kann bestätigen, dass das Phänomen auch mit Umbenennung und ohne den (umständlichen) Aufruf funktioniert.
Umbenennung:
test.docx -> test.DOCX
Doppelklick auf die Datei
Veränderung
Schließen per X mit Speichern nach Aufforderung
Datei ist weg (Papierkorb)
Wenn man nicht explizit die Datei nochmal sucht oder öffnen will geschieht der Fehler unbemerkt und fällt eventuell erst spät auf, wenn kein Backup der Datei mehr existiert. Insofern durchaus gefährlich
"Schließen per X mit Speichern nach Aufforderung"
Was passiert, wenn du erst normal speicherst (Datei, speichern) und erst danach normal beendest (Datei, beenden)?
Ist die Datei dann auch weg?
Ich bin zwar nicht der den du gefragt hast, aber bei mir tritt das Problem nicht auf wenn ich zuerst den Speichern Button drücke und dann Word beende.
Für mich reproduzierbar:
Windows 11 Business (10.0.22631 Build 22631)
Microsoft® Word 2016 MSO (Version 2409 Build 16.0.18025.20030) 64 Bit
Speicherort war der Dokumente-Ordner via FolderRedirection.
Datei wird aber nicht vollständig gelöscht, sondern lediglich in den Papierkorb verschoben.
Den Kommentaren zu folge, scheint dann ja "nur" der Current Channel betroffen zu sein
https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date
Klingt für mich eher nach einem übereifrigen Virenscanner.
Dann müsste das aber der Defender sein… Sonst läuft auf den von mir getesteten Geräten nichts.
Dann landet die Datei aber nicht (wie hier in anderen Kommentaren beschrieben) im Systempapierkorb.
Win 10 Busi. 19045.4894
Word 365 2407 17830.202010
nicht reproduzierbar …
Win 10 Pro 19045.4894
Office 2021 LTSC 16.0.14332.20771
Symantec EP
nicht reproduzierbar
Office 2016, Problem nicht reproduzierbar.
"Der Leser merkt an, dass so ein Aufruf evtl. von Dokumentmanagement-Systemen (DMS) verwendet wird. Hier können massenhaft Dateien verloren gehen."
Wenn dieses DMS in %SystemDrive% schreibt, gehört der Vertrag gekündigt und die Anwendung entfernt.
unser DMS schreibt auf ein Netzlaufwerk. Der Pfad spielt keine Rolle.
C:\test.RTF war ein Beispiel
Führt an dieser Stelle nicht weiter – ich möchte wissen, ob das Einzelfall ist (wurde ja von mehreren Lesern bestätigt, dass die das Verhalten ebenfalls sehen). Ich habe obigen Text dergestalt erweitert, dass die Dokumentdatei im Profilordner Dokumente erzeugt und dann getestet werden sollte. Ist der Fehler dann immer noch da?
naja scheint ja nur das aktuelle (24xx) Office 365 betroffen zu sein, andere Versionen nicht. Da pfuscht wohl die KI Funktion rein ;-p
Virenscanner ist es jedenfalls nicht der verschiebt nicht in den Papierkorb, der löscht direkt und Quarantäne. Papierkorb bei Virenscanner wäre äusserst fatal, so dumm ist MS nichtmal mit dem Defender.
Für mich nicht reproduzierbar.
Welche Versionen von Office und Windows benutzt du denn?
Ohne diese Angaben ist eine Meldung wertlos.
reproduzierbar unter:
Win 11 23H2 mit MS365 2409 und ESET als AV.
nicht reproduzierbar unter:
Win Server 2019 RDS mit MS Office ProPlus 2019 und ESET als AV.
Ich habe noch weitere Tests mit aktuellem Office365 Version 2409 (Build 18025.20104) durchgeführt:
Word – DOCX: reproduzierbar
Word – DOC: reproduzierbar
Powerpoint: PPTX nicht reproduzierbar
Excel – XLSX: nicht reproduzierbar
Excel – CSV: Speichern beim Schließen überhaupt nicht möglich, wenn der aufruf mit Parameter -t erfolgt (egal Endung ob klein oder großgeschrieben) – Speichern Dialog ploppt immer wieder auf, könnte aber auch ein anderes Problem sein
Für mich nicht reproduzierbar. (soll nicht heißen, dass ich das für Humbug halte!)
Windows 11 23H2 (Build 22631.3169) mit Microsoft 365 MSO (Version 2407 Build 16.0.17830.20210) 64 Bit.
AV ist CrowdStrike.
Office 2019 LTSC, Windows 2019 Terminalserver, nicht reproduzierbar
Hallo, bin ein fleissiger Mitleser, auch bei mir ist das Verhalten reproduzierbar.
Einzelplatz-PC mit Win11 23H2 (Build 22632.4249), MS365, nur Defender.
Ich hab unter Downloads eine rtf-Datei erstellt, in *.RTF umbenannt, etwas hineingeschrieben und beendet mit speichern.
Schwups wurde die Datei in den Papierkorb verschoben.
Zu "MS365" fehlen noch die Version und die Build-Nummer.
Hallo, hab ich im Eifer Vergessen:
Office365 Version 2409 (Build 18025.20104)
Ich habe übrigens inzwischen auf Win 11 24H2 upgegradet.
Das macht schon mal keinen Unterschied. Dereselbe Effekt.
Gruß, Ralf
Das kann an den Sicherheitseinstellungen zum Schutz vor unsicheren Dateiformaten liegen.
RTF-Dateien sind nämlich bekanntermaßen so riskant, dass Microsoft selber diverse Sicherheitsrichtlinien eingebaut hat.
Kann man sehen und ändern entweder über die Registry oder über den Gruppenrichtlinien-Editor.
Schaut mal in die Registry, ob bei euch dir RTF-Files blockiert sind.
HKEY_CURRENT_USER -> Software -> Policies -> Microsoft -> Office -> [Version] -> Word -> Security -> FileBlock (und FileOpenBlock)
Im rechten Fenster steht dann eventuell "RtfFiles" und als Wert 0 bis 5 mit Bedeutung:
"0" (nicht blockieren),
"1" (Speichern blockiert),
"2" (Öffnen gemäß Standardverhalten),
"3" (blockieren),
"4" (geschützte Ansicht öffnen),
"5" (Bearbeitung in geschützter Ansicht)
www[.]windowspage[.]de/tipps/025942.html
Könnt ihr ja mal nachschauen und zum Testen eine 0 eintragen, ausloggen, neu einloggen, und nochmal probieren, die RTF zu speichern.
Bei meinem Test war ich überrascht, dass Word das Öffnen von RTF verweigert mit Meldung:
"Sie versuchen, einen Dateityp zu öffnen, der durch die Registrierungsrichtlinieneinstellung blockiert wird."
Das hatte ich vor Jahren mal so eingestellt, dass RTF blockiert wird und inzwischen wieder vergessen.
Bei neueren Office-Versionen geht es eventuell auch über die Optionen -> Trust Center
learn[.]microsoft[.]com/de-de/office/troubleshoot/settings/file-blocked-in-office
Für den Gruppenrichtlinieneditor braucht man eventuell die passenden "Administrativen Vorlagen" (ADMX-Templates) für die benutzte Office Version, damit es im GPO-Editor die Option gibt.
GPO-Editor -> Benutzerkonfiguration -> Administrative Vorlagen -> Microsoft Word 2010 (bzw die jeweils benutzte Version) -> Word-Optionen -> Sicherheit -> Sicherheitscenter (bzw Trust Center) -> Einstellungen für den Zugriffsschutz ->
Im rechten Fenster "RTF-Dateien" -> "konfigurieren" ->
[x] Aktivieren -> eine der 6 Optionen einstellen -> OK
Deine Idee ist gut, allerdings sind DOC und DOCX auch betroffen.
Somit würde ich das als Ursache ausschließen.
Steht in der Ereignisanzeige (eventvwr.msc) eine passsende Meldung zur Verschiebung einer Datei in den Papierkorb?
abgesehen von Events der Informationsebene "Informationen" (die auch ohne das Problem beim Start von Word auftreten) konnte ich nichts finden. Weder in den Windows Protokollen noch in den Anwendungsprotokollen "Microsoft Office Alerts"
ehm warum ruft man word überhaupt mit parameter /t auf? was ist das spezielle daran?
Wie gesagt gibt es DMS Systeme welche diesen Aufruf verwenden um Dateien zu öffnen. Und wenn da hunderte Leute jeweils mehrere Dateien bearbeiten kommt da was zusammen.
Ferner ist inzwischen klar, dass sich das Problem nicht auf den Aufruf beschränkt, sondern auch bei Umbenennung und "normalem" Öffnen auftritt. Kann also auch den Privatanwender, der gerade an seiner Abschlussarbeit sitzt treffen.
Das gefährliche an dem Bug finde ich, dass man davon ausgeht, dass die Datei ordentlich gespeichert wurde und eventuell nichts davon bemerkt. Die wenigsten Anwender kontrollieren wohl nach dem Speichern ob die Datei wirklich noch da ist.
Bei Terminalservern oder sonstigem wird der Papierkorb des Users evtl. beim loggoff automatisch geleert. Bei Privatanwendern evtl. ohne zusätliche Kontrolle der Papierkorb geleert. Und schon sind die Dateien weg, ohne dass jemals ein Backup davon erstellt wurde.
hm…hat Microsoft in seinem Wahn, RTF eine neue, andere Bedeutung gegeben, aber in voller Arroganz vergessen, das zu dokumentieren?
Vielleicht für Replay Time Format?
Oder wollte es und dann fiel auf, dass NTFS eigentlich nicht Case sensitive ist und man hat es, schnell schnell, unvollständig rausgebastelt?
Es ist krank das man sich über solche Dinge Gedanken machen muss. Krank.
Es ist in der Tat krank, aber deine Gebete werden erhört (wenn du mitziehst):
Die Zukunft in der EU ist:
https://opendesk.eu/
+
sonstige Anwendungen als WebApps
+
Linux Desktop (oder sonstiges, hauptsache Browser läuft)
+
ARM Prozessor (oder sonstiges, hauptsache Browser läuft)
Paar Jahre Geduld noch und entsprechende Vorreiter, die es wagen und dann wird der Traum wahr. Das Ende von MS ist absehbar.
Ist ein bisschen OT da es nichts mit dem geschilderten Verhalten zu tun hat.
Auch wenn es sehr wünschenswert wäre, ich glaube ehrlich gesagt nicht daran, dass diese neue Lösung ernsthaft eine Chance hat. Ansonsten hätten sich alternative Office Pakete schon längst durchgesetzt. Spätestens wenn irgendeine andere Software (die im Zweifel sehr teuer war) mit dem Office Paket interagiert und da nur MS-Office kompatibel ist bzw. supported wird ist da Ende im Gelände.
Das wird fürchte ich genau so eine Totgeburt wie die "EU-Cloud" Gaia-X, oder wie die hieß.
Es gibt da doch so ein nettes Tools von Sysinternals, Filemonitor hieß das mal.
Eigentlich genau das Richtige um zu sehen, wer da an der Datei/Direktory Eintrag rumfummelt.
Vielleicht will Word die Alte Datei umbenennen, was nicht klappt, weil Word die Endung rft selbst rangebastelt hat und dann trotz der vermeintlichen Umbenennung im Nächsten Zug die alte Datei, wo Word die Erweiterung RTF nicht ersetzt hat, weil es den Originalen String verwendet, in den Papierenkorb verschiebt.
Aber: Es sollen ja schon Pferde gesehen worden sein, die vor Apotheken….
Reine Vermutung:
Wenn man eine Datei in Word zum Bearbeiten öffnet dann wird eine versteckte Datei namens ~$Dateiname im selben Verzeichnis angelegt.
Wahrscheinlich geht etwas schief wenn diese Datei dann zurückgeschrieben wird auf den ursprünglichen Dateinamen.
Weitere neue Erkenntnisse:
die Änderung von einzelnen Buchstaben der Dateiendung verursacht das gleiche Problem z.B. docx -> doCx
Bei Öffnen der Dateien mit Editor oder LibeOffice ist das Problem nicht produzierbar.
Für mich ganz klar "Word Current Channel Problem bei geänderten Dateiendungen".
jepp.
Jedenfalls ist mir so ein Anfänger Fehler schon untergekommen.
(Natürlich nicht bei meinem Code, niemals nicht)
Der Code ging durch alle Tests, bis irgendwer gemischte Groß Kleinschreibung wollte und sich beschwerte, das die geplättet wurde.
Denn die erste Lösung war, die ein kommenden Dateinamen "to lower" zu geben (Sagte ich schon: "Traue niemals Externen Daten "?)
Aber wie gesagt, mit dem Filemonitor wäre das vermutlich zu finden.
Windows 11 Pro Build 22631.4169
Office 365 Version 2409 Build 16.0.18025.20030 64 Bit
Windows Defender
Beschriebenes Verhalten ist nicht reproduzierbar.
Mir wurden aber die letzten Tage Meldungen von Kunden weitergetragen, bei denen in der Software Word Dokumente (docx und rtf) verschwunden waren, die daraus erzeugten PDF Dateien allerdings noch vorhanden waren. Ob es hier einen Zusammenhang gibt, kann ich aktuell nicht sagen.
Zitat aus dem Artikel:
"sobald die Dateinamenerweiterung .RTF in Großbuchstaben geschrieben wird."
–
1a.
Inzwischen hat sich herausgestellt, dass es nur einen einzigen Großbuchstaben benötigt und nicht die komplette Dateinamenerweiterung in Großbuchstaben geschrieben sein muss.
1b.
Es ist nicht auf RTF beschränkt, sondern gilt auch für .DOC und .DOCX und eventuell auch für .CSV.
#####
2.
Zitat:
"Ein Word-Dokument mit WINWORD.EXE /T C:\test.RTF anlegen lassen"
–
Parameter "/T" ist nicht nötig für den Effekt.
kann ich bestätigen.
Verdammt. Irgendwie regt sich bei mir das andere Neuron, wenn ich das höre…da war mal was…
Hatte Microsoft im Zuge seiner Linux Initiative, und den kaputte Restores bei unterschiedlicher Schreibweise der unter Linux unterschiedlichen Dateien was gebastelt?
Ganz früher gab es Probleme mit LPT CON in Datei Namen.
Aber passt ja nicht.
Ist eindeutig klar, dass die File Assoc für "DOC" das identische Kommando wie für "doc" erzeugt?
Was passiert, wenn die Datei auf der Platte
DOC trägt, der Aufruf aber mit doc erfolgt und vice versa? (Oder RTF)
Bisherige Zusammenfassung der 6 betroffenen Systeme:
1.
User: J.
Microsoft Word 2016 MSO (Version 2409 Build 16.0.18025.20030) 64 Bit
-> [Current Channel]
Windows 11 Business (10.0.22631 Build 22631)
2.
User: Hu Ju
Word 2409 Build 18025.20104
-> [Current Channel]
Windows 11 23H2 22631.4169
3.
User: Anonymous
Word für Office 365, Version 2409, build 16.0.18025.20030 – 64 bit
-> [Current Channel]
windows 10, 22h2, build 19045.4957
4.
User: Fred
MS365 2409 (Build-Nummer fehlt)
-> [Current Channel]
Win 11 23H2
ESET als AV
5.
User: Ralf
MS365 (Version und Build-Nummer fehlen)
Win11 23H2 (Build 22632.4249)
Defender.
6.
User: held
Office365, aktuellste Version, Release vom 25. Sept.,
also Version 2409 und Build 18025.20104
-> [Current Channel]
Windows 10, Windows 11, Server 2022
Betroffen sind also [Current Channel] Versionen von Office.
Seltsam:
User Jan-Niclas hat die selbe Version 2409 und die selbe Buildnummer 16.0.18025.20030 [Current Channel], ist aber nicht betroffen (Windows-Build ist identisch mit der vom betroffenen User Hu Ju).
bezüglich Jan-Niclas
Wenn ich diese Versionsnummer suche
16.0.18025.20030
sieht es für mich nach einer Preview Channel Version also Beta aus.
bin aber kein Experte was Microsoft Versionsverwaltung angeht und möchte es auch nicht werden.
Ferner habe ich festgestellt, dass sich meine eigene Office Versionsnummer wohl soeben auf genau diese Versionsnummer downgegradet hat.
Ich hatte vorher die Build 18025.20104 die ich oben per copy+paste reinkopiert und ganz sicher nicht abgetippt habe. Hier passieren wohl magische Dinge.
Du hast Recht
Version 2409 – Build 18025.20030
ist die Preview (Vorschau)-Version des [Current-Channel] vom 9. September 2024
learn[.]microsoft[.]com/de-de/officeupdates/update-history-current-channel-preview
2.
Version 2409 – Build 18025.20104
ist die normale Version (nicht Preview) des [Current-Channel] vom 25. September 2024
learn[.]microsoft[.]com/de-de/officeupdates/update-history-microsoft365-apps-by-date
3.
Downgrade (!) auf das vorherige verbuggte Preview von 16 Tagen zuvor (welches vorher gar nicht installiert war?) ist ein echter Hammer.
Noch dazu, wo das Preview so einen Amok-Delete-Bug hat.
Wurde Build 18025.20104 offiziell zurück gezogen, etwa wegen dieses Bugs?
…und dann merkt Microsoft nicht, dass das Preview genau den selben Bug hat?
Drückt Microsoft einfach zwangsweise die Preview-Versionen (Beta) in die Systeme rein, ohne Kenntnis und ohne Zustimmung der User?
Vielleicht liest Microsoft hier im Blog mit und ist aktuell noch am rumstümpern, um den Bug durch heimlichen Rückzug der Updates zu fixen, bevor es Sammelklagen gibt wegen fehlender Dateien.
Nein, ich habe eine andere Erklärung – aber genauso abstrus: Ich habe zwei verschiedene Build-Nummern, je nachdem an welcher Stelle ich schaue.
Unter Produktinformationen gibt es
a) den Button "Info zu Word" mit Build 16.0.18025.20030 und
b) rechts daneben nochmal den Text "Info zu Word" mit Build 18025.20104
Die 16.0.18025.20104 scheint tendenziell die richtige Nr. zu sein, die wird jedenfalls unter "Installierte Apps"auch für das Gesamtpaket "MS 365 Apps for Blablabla" angegeben.
Hallo,
darüber hab ich mich beim Nachtragen der Build-Nr. auch gewundert.
Für das Ofdfice-Paket wird 18025.20104 und für Word, Excel, Powerpoint 16.0.18025.20030 angezeigt.
Gruß, Ralf
1. Dateien junk.DOCX und junk.DOC in Order auf dem Desktop erzeugt.
2. Jeweils per normalem Doppelklick geöffnet, in Word geändert, Word-Fenster geschlossen, und bei Nachfrage 'Save' bejaht.
3. Dateien sind weg, aber im Papierkorb anscheinend mit allen Änderungen wieder auffindbar.
4. Verschiebe Dateien zurück in Anfangsorder, und goto 2, und wiederhole bis zum Abwinken…
Windows 10 LTSC 1809, Build 17763.6293
Office 365 Version 2409, Build 18025.20104 current channel
Mein Office hat sich innerhalb der letzten 1-2 Stunden automatisch ohne Zutun downgegraded auf build 16.0.18025.20030 von ehemals Build 18025.20104 wie oben copy pasted.
behoben ist das Problem nicht.
zum Thema Versionen nur noch folgendes:
Die Build Nummern von Word und Office allgemein weichen voneinander ab. Wir vergleichen also Äpfel mit Birnen und ich bin selbst auch drauf reingefallen.
https://pasteboard.co/ojnDHyPVQd5C.jpg
Das Problem ist per Feedback an MS reported.
Ich bin jetzt raus hier.
>>> Die Build Nummern von Word und Office allgemein weichen voneinander ab.
Das kann ich so nicht bestätigen. Bei Outlook (classic), Word, Excel und PowerPoint werden jeweils die selben zwei o.g. Build-Nummern genannt. Beide Nummern scheinen sich also jeweils auf das Gesamtprodukt zu beziehen.
Bist du sicher? Oder hast du die Nummern einfach nur an zwei verschiedenen Stellen abgelesen? Siehe meinen anderen Post oben dazu.
Moin Test ist Reproduzierbar
Dateien werden, WENN MINDESTENS EIN BUCHSTABE, EGAL WELCHER in der Endung GROß geschrieben ist .odT,.rTf,.dOc,.DocX, gelöscht
Ablauf.
nachdem ändern des Inhaltes, in der Datei und dem Schließen und Speichern im Word über das X ICON, wird die Datei sofort gelöscht, Fatal natürlich bei laufenden Reinigungsscripts und Netzwerkordnern ohne Papierkorb!
hingegen keine Probleme, bei Autospeichern oder Speicher über das Menü und Kleinschreibung der Datenendung
Probleme vorhanden
Win11 24H2 + Office365 V2409 – Build 18025.20104 (AV ESET oder Kaspersky)
keine Probleme vorhanden
Server 2019/2022 TS + 64bit Office 2019 V1808 – Build 10414.20002 (mit und ohne Defender)
Macht es einen Unterschied, wenn besagte Dateien das Schreibschutz-Attribut gesetzt haben?
Und wenn man so eine Datei von CD/DVD öffnet? Was passiert dann? Stürzt Word oder gleich das ganze Windows-System ab? Oder ist nachher ein Loch in der CD – uhhhhh !!
Übrigens hat jemand eine Erklärung, warum unter Win 10 (22H2) ab und zu im Tastmanager ein Office 365 -Hintergrundprozess zu sehen ist, wenn man gar kein MS Office auf dem System hat, weder ein 365 noch eine Fest-Installation irgendeiner Version ??? Der unerwünschte MS-Dreck schleicht sich überall ein … ob man will oder nicht …
liegt wohl daran das sie dir unter apps die Probe Office reindrücken wenn du nicht entsprechend abgedreht hast.
Ne Anekdote am Rande: Mein Outlook (classic) meldet gerade beim Versuch, dort einen Text hineinzukopieren: "Ein Problem wurde von Word festgestellt." Dissoziative Identitätsstörung?
Moin,, das mit # kann ich Bestätigen.
Aber noch was vielleicht seltsames, Drückt man STRG + Z nach dem Löschvorgang, seitens WORD, erscheint die Datei wieder am Ablageort!
Daß Dateien nach dem Speichern verschwinden kenne ich von Excel auf DFSR-Laufwerken, da ist es wohl ein Timing-Problem.
Nachtrag
auch interessant "Datei wurde per Doppelklick geöffnet."
Aufgefallen ist mir (außer STRG + Z zum Zurückholen der Datei im Lokalen Ablageordner)
das auf Netzlaufwerken, Dateien mit # im Namen oder Großbuchstaben in der Endung, die folgende Meldung zusätzlich erscheint.
(1) normal Meldung: Ihre Änderungen an dieser Datei speichern?
(2) untypisch Meldung: Eine Datei namens dateiename.DOCX ist bereits vorhanden. Möchten Sie sie durch diese ersetzten?
Bejahe ich diese Meldung, ist die Datei danach weg wie bekannt.
Diese Meldung bekomme ich aber nicht auf dem Lokalen PC Laufwerk!
Verwende ich auf dem Netzlaufwerk nicht die Kombination # im Namen oder Großbuchstabe in der Endung bekomme ich keine 2 Meldung!
Woher kommt das Netzlaufwerk?
Unter Unix kann "#" eine besondere Bedeutung haben. Passwörter mit diesem Zeichen gaben oft Rätsel auf, warum man sich nicht damit erneut anmelden konnte.
Aber das ist Jahrzehnte her
Wenn jemand Zeit und Lust hat darf er oder sie mal FileMon(SysInternals) anmachen und tracken wer oder was die jeweilige Datei als gelöscht markiert.
(AV schmeisst Dateien nicht in den "Papierkorb", Word schmeisst alte Versionen einer Datei vor dem speichern auch nicht in den "Papierkorb" – so eine Logik stirbt aber schnell wenn der Code die Gross- und Kleinschreibung im Namensvergleich nicht ignoriert — und das ist doch der Elephant im Raum.)
habe dieses Event gefunden:
Process Name: WINWORD.EXE
Path: C:\test.DOCX
Operation: SetRenameInformationFile
ReplaceIfExists: False
FileName: C:\$RECYCLE.BIN\S-*****-*****\$RWUOHFA.DOCX
Beachte meinen Nachtrag am Artikelende.
Das ist für mich aber keine Lösung.
Erstens ist es Standard, dass dieser Einstellung nicht angehakt ist und zweites darf Word wegen einer Einstellung, welche nur die Ansicht verändert noch lange keine Dateien löschen.
Sehe ich auch so, Microsoft muss schleunigst nacharbeiten. *Bananen Reifen beim Kunden*
Extremst gefährlich dieser Mist und Trend.
Wir als IT Menschen/Admins müssen den Rotz mal wieder ausbaden und können nur zugucken und mit Glück Downgrades durchführen mit seinen Folgen.
In Firmen Lösbar aber der Rest an Kleinkunden oder Endverbrauchern, nicht daran zu denken.
*Backstage beim Öffnen oder Speichern von Dateien nicht anzeigen*
Bei Office 365 war das die Lösung, ist aber Standardgemäß nicht aktiviert und daher ein Pflaster aber keine Heilung/Lösung.
Also ein O365 Problem, denn bei Office 2019/2021 ist es auch Deaktiviert und da habe ich keine Probleme.
Altes Testsystem Win10 22H2 April 2024 – Office 365 16.0.16827.20166 Alles noch OKAY
nach Upgrade ohne Neustart auf 16.0.18025.20030 64Bit, werden die Daten sofort gelöscht.
Wie immer ein Dank an Spürnasse Günter, Danke :o)
"Also ein O365 Problem, denn bei Office 2019/2021 ist es auch Deaktiviert und da habe ich keine Probleme."
Ja, so ist es bei mir im Büro auch. Da hab ich Office 2016. Da ist auch kein Häkchen gesetzt. Die Dateien bleiben erhalten.
Beschriebenes Verhalten ist bei mir nicht reproduzierbar.
Microsoft Windows 11 Pro Version 10.0.22631 Build 22631
Word 2019 MSO (16.0.10414.20002) 64Bit
Moin,
ich kann bestätigen, dass die im Artikel genannte Backstage-Lösung das Problem bei mir behhoben hat.
Eine schöne Restwoche noch.
Wird die Datei auch dann gelöscht, wenn sie auf OneDrive liegt?
Warum greift diese "Backstage"-Option überhaupt?
Die bezieht sich doch ausdrücklich nur auf "Tastenkombination", aber ein Mausklick auf das X zum Schließen und Mausklick auf den "Speichern"-Button sind beides keine Tastenkombinationen.
"Backstage" zeigt doch nur eine Liste der zuletzt verwendeten Dateien an.
Warum hat so eine zusätzliche Listenansicht überhaupt irgend eine aktiv löschende Auswirkung auf gespeicherte Dateien?
Warum ist Backstage case-sensitive im Gegensatz zur jahrzehntealten Microsoft-Doktrin, dass alles case-insensitive sein soll, damit es besser bedienbar ist?
Das sind doch mindestens 3 Fehler in der Programm-Logik (1. keine Tastenkombi, 2. nur lesende Liste, 3. case-sensitive).
Die Option mit der Backstage verändert auch die Ansicht des Speichern Dialogs beim Schließen.
Warum auch immer. Die Option war mir zuvor nicht bekannt und ich musste erstmal googeln was überhaupt eine Backstage ist.
Sowas weiß man wohl nur als Microsoft MVP.
Wenn die Datei auf OneDrive liegt, dann wird sie nicht gelöscht.
answers[.]microsoft[.]com/de-de/msoffice/forum/all/kritischer-bug-word-l%c3%b6scht-dateien-nach-dem/f622cbac-706d-4521-a7b3-704c31f484e2?page=1
Ich habe genau das gleiche Problem. Mindestens bin ich nicht alleine da. Hoffentlich bekommt MS das in den Griff.
Backstage ist nicht aktiv und trotzdem funktioniert es nicht, sprich die Datei wird nicht gelöscht. Ich denke da ist noch was anderes
Liegt die Datei auf Onedrive oder benutzt du keine Version 24xx Build 18025.xxxxx (Current Channel)?
Konnte schon jemand mittels Process Monitor nachvollziehen, welches Programm überhaupt die Manipulation vornimmt? Oder geht das nicht, weil der Virenscanner den Process Monitor als PUA ansieht und man schiss hat, so ein pöhses Tool zu nutzen, resp. den Abteilungsleiter fragen müsste, der genervt antworten könnte:Ihre Kollegen brauchen das Tool doch auch nicht.
Sorry, mich stört dieses rumpobieren echt, nett gesagt.
Das muss ja irgendwer programmiert haben, oder fallen Fehler bei Microsoft jetzt direkt vom Himmel?
Man kann mit dem (hoch komplexen) Process Monitor genau sehen, was da gemacht wird.
Ja, das ist Lame.
Wenn ich ne neue Gardine brauche, kaufe ich auch immer solange welche bis es passt. Einen Meterstab benutze ich nicht. Das ist ja so viel spannender und irgendwann wird schon klappen…war immer so.. wozu messen?
Im Windows-Eventlog steht Winword.exe als Auslöser für die Löschung in den Papierkorb.
auslösende Funktion: SetRenameInformationFile
siehe Beitrag von held:
https://www.borncity.com/blog/2024/10/02/loescht-microsoft-word-rtf-dateien-wegen-grossschreibung/#comment-194574