Der Pfad- und Dateiname der Datei war länger als 256 Zeichen, die das WINDOWS-Betriebssystem zulässt. Daher wurden die überzähligen Zeichen als Dateiendung interpretiert. Die Dateiendung wird auch als Dateiattribut bezeichnet, die hier nun aus mehr als drei Zeichen bestand und daher ungültig war.
Stop! Nicht schon wieder so einen Quatsch behaupten... So viele Fehler in so wenig Text...
- Die Grenze für Pfad- und Dateiname wird bei FAT auf 256 Zeichen begrenzt, NTFS kann mehr, Windows beschränkt gern auf 260 Zeichen (davon bis zu 256 für Dateiname und/oder Pfad), kommt aber mit längeren auch klar und man kann seit Windows 10 auch explizit längere Namen erlauben, dann werden es ca. 32.767 Zeichen.
- Die Dateiendung zählt dabei mit!
- Es werden also auch keine überzähligen Zeichen abgeschnitten und als Dateiendung interpretiert
- Die Dateiendung bezeichnet man nicht als Dateiattribut. Je nach Interpretation von Attributen kann man diese zwar als alle Metadaten einer Datei, inklusive Dateiname mit Endung, ansehen, in der Regel werden hierunter aber "nur" die Attribute wie Zeitstempel, Berechtigungen und Markierungen wie Schreibschutz, Archiv, versteckt oder Systemdatei verstanden.
- Dateiendungen müssen nicht mehr maximal drei Zeichen haben. Mehr als drei Zeichen sind nicht ungültig. Im Gegenteil: Es wäre sogar erlaubt, eine Datei mit 0 Zeichen Länge zu benennen, aber mit 256 Zeichen Dateiendung.
Mist, Google setzt wohl immer seltener auf real-existierende Beiträge und sucht KI (künstliche Idiotie) mehr nach ähnlichen Treffern.
Ja, leider... Man tippt was ein und Google sucht was anderes, was man meinen könnte... Echt nervig. Abhilfe: Suchbegriffe in Anführungsstriche setzen. Dann sucht er nach exakt dem Begriff und er muss auch zwangsläufig vorkommen. Keine Suche nach Ähnlichkeiten mehr und keine Suche mehr, bei dem einzelne Teile ignoriert werden. Setzt man mehrere Worte zusammen in Anführungsstriche, wird auch genau nach dieser Abfolge gesucht.
Zum Problem:
Neben den direkt sichtbaren Attributen gibt es auch noch weitere "extended attributes" und Forks. Bei Linux gern als xattrs bekannt, bei Windows bzw. NTFS kennt man sie als "alternate data streams" (ADS)
Wenn ich nun den Fehler richtig verstehe (ist jetzt aber auch nur gegoogeltes Halbwissen), ist das Problem folgendes: Der Zugriff auf ADS passiert, in dem man einen Doppelpunkt hinter den Dateinamen schreibt und dahinter den Namen des ADS (was wiederum eine Datei sein kann bzw. ist). Wenn die Datei Test.txt also den ADS mit dem Namen Zusatz.txt beinhaltet, dann greift man per Test.txt:Zusatz.txt darauf zu. Wenn der alternative Datenstrom jetzt aber selbst einen Doppelpunkt im Namen hat, gibt's ein Problem, da der Doppelpunkt schon für die "Abtrennung" zwischen ADS und eigentlicher Datei reserviert ist. Das wäre ein Beispiel für einen ungültigen Namen eines ADS und die Fehlermeldung scheint von einem solchen zu "reden". Kann natürlich auch noch weitere ungültige Namen von ADS geben, dazu könnte man sich mal die Namen der ADS auflisten lassen, siehe unten.
Dass sich das durch zippen beheben lässt, liegt daran, dass die meisten Packprogramme alternative Datenströme und erweiterte Attribute entweder beim Packen oder beim Entpacken oder bei beidem ignorieren (es sei denn, man setzt explizit Optionen, die das Kopieren der ADS/xattrs erzwingen). Nach zippen und entzippen sind die ADS also weg und damit auch der ADS, der einen nicht erlaubten Namen mit Doppelpunkt hatte.
Du könntest mal eine Kommandozeile in dem Ordner öffnen, wo die betroffene Datei liegt (Shift+Rechtsklick, dann Kommandoziele öffnen oder PowerShell öffnen) und "dir /r" eintippen. Das sollte die Namen alternativer Datenströme mit ausspucken. Hoffe ich zumindest - vielleicht schmiert der Befehl aber mit dem gleichen Fehler ab? Einen Versuch wäre es wert.
Wikipedia zeigt dann eine Möglichkeit, um auf der Kommandozeile alle ADS zu löschen:
https://de.wikipedia.org/wiki/Fork_(Dateisystem)#Entfernen_eines_ADS aber keine Ahnung, ob das mit nicht-Textdateien funktioniert, hier wird nämlich ein Kommando für Textdateien genutzt ("type"). Eventuell ist das zippen/entzippen schneller und einfacher
Und keine Ahnung, ob man hier nicht auch wieder auf den Fehler stößt? Sollte aber eigentlich nicht, da auf diese Art ja nicht auf ADS zugegriffen wird. Sonst würde das zippen auch fehlschlagen.
