Windows Fehler 0X800700FE , der angegebene Name des erweiterten Attributs war ungültig

[AndreasBloechl]

Was hat dieser Fehler auf sich?
Ist mir gestern untergekommen als ich mit BeyondCompare eine ext. HDD sichern wollte auf eine zweite ext. HDD, mit dem WindowsExplorer konnte ich diese Datei auch nicht rüberkopieren. Einzig wie ich diese Datei auf die andere Platte bekommen habe war zuvor zippen und dann auf der anderen Platte entpacken.
Dieser Fehler ist mir noch nie untergekommen. Vielleicht kennt das jemand von euch.

 

[albert66]

Nur kurz vorab zu @cuco - mit dir /r geht bei mir nichts. Hilfreich aber der Tip auf sysinternals. Ich habe mir streams gezielt downloaded und getestet. https://learn.microsoft.com/en-us/sysinternals/downloads/streams . Ich hänge einfach den ersten Test an, ein paar XXXX um den realen Namen zu löschen. Die .....property:$data schaue ich mir später an.

Bisher hatte ich nur einen Vergleich, daß die Org-file-propertys und kopierte Nas-file properties unterschiedlich waren, aber im wesentlichen security etc., d.h. Zugriffsberechtigung. Die eigentliche Mail-file und die NAS-copy (backup) habe ich mit fileanalyzer verglichen - NAS ohne die ADS, aber die File selbst 100pro identsich, mit checksums und allem. D.h. für den eigentlichen Backup sind die ADS nicht nötig, weil die .eml inkl. Anhänge und ohne ADS ohne weitere Unterschiede im Mailer lesbar sind.

Was da im ADS ist, ...... muß heute Schluß machen, aber das schaue ich mir später noch an. Das Arbeiten mit Streams (nur display) ist problemlos, aber Aufruf siehe meine upload (copy power-shell). Danke für die Tips, mit OS/2 ext.-Attributes bin ich fit, aber die Win----Heimlichtuerei war mir neu .
Gruß Peter

(Kopiere Text rein, als file zu umständlich. Der NAS ist Medion Life P89636 (etwas älter für die alten PCs gedacht, jetzt i.R. Reserve). (typos noch korrigiert, hoffentlich alle, mir pressierts, aber das war jetzt zu interessant ...)
------------------------------------------------
Suggestion [3,General]: The command streams64 was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. If you trust this command, instead type: ".\streams64". See "get-help about_Command_Precedence" for more details.
PS N:\tmp> .\streams64 -s *.eml

streams v1.60 - Reveal NTFS alternate streams.
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

N:\tmp\xxxxxxxxxxxxx.eml:
:OECustomProperty:$DATA 16531
N:\tmp\xxxxxxxxxxxxx.eml:
:OECustomProperty:$DATA 616
N:\tmp\xxxxxxxxxxxxx.eml:
:OECustomProperty:$DATA 4329
N:\tmp\xxxxxxxxxxxx.eml:
:OECustomProperty:$DATA 692

PS N:\tmp> .\streams64 -s \\nas-xxxxxx\public\tmp\*.eml
......
No files with streams found.

PS N:\tmp>
------------------------------------------------------------
Nachtrag: dir /r funktioniert vom normalen "command prompt", nur nicht via "power shell", sorry, Peter

 

[der_ingo]

cuco, man kann nicht alles als "Quatsch" bezeichnen, was man selbst nicht versteht:

Aber warum schreibst du dann aus voller Überzeugung irgendwelche Dinge (ab), die du ganz offensichtlich nicht verstehst? Nicht einmal, nachdem cuco es oben entsprechend erklärt hatte.

Du bist offenbar weiterhin der Meinung, dass Erweiterte Attribute irgendeinen Zusammenhang mit dem Dateinamen haben. Das ist schlicht falsch. Und auf der Basis ist der Rest dann auch an den Haaren herbei gezogen.
Dass NTFS maximal 256 Zeichen plus Dateiendung verwenden würde, ist schlicht falsch. Dass daran ein Registry-Parameter etwas ändern würde, ist ebenfalls ganz einfach falsch.

Die Aussage mit der MAX_PATH Variable hast du schön von der Microsoft Webseite abgeschrieben, aber nicht gesehen, dass es dazu noch ein paar Bedingungen gibt. Der Registry-Key hebt die Pfadbeschränkungen gar nicht generell auf, sondern nur für Programme, die darauf angepasst sind und es entsprechend in ihrem Manifest deklarieren.
Man sollte halt nicht nach dem ersten Absatz aufhören zu lesen und möglicherweise auch Links folgen...

Maximum Path Length Limitation - Win32 apps

Maximum path length limitation.

learn.microsoft.com

Deine Aufzählung ist eine Mischung aus Halbwissen und schlicht völlig falschen Behauptungen. Das kann man sehr gut mit "Quatsch" zusammenfassen.

 

[AndreasBloechl]

Oje, ich kann euch Profis da überhaupt nicht mehr folgen.
Aber ich werde das mal noch genauer testen wenn ich Zeit habe, normal hängen bei mir alle HDDs bis auf eine einzige Sicherung an der NAS und werden über diese dann synchronisiert vom PC aus über BeyondCompare. So erspare ich mir die ständige umstöpslerei.

 

[cuco]

• 260 Zeichen minus Punkt und drei Zeichen sind genau 256 Zeichen Zeichenlänge für einen Dateinamen einschließlich Pfadangabe.
• In Windows-Editionen vor Windows 10 Version 1607 beträgt die maximale Länge für einen Pfad MAX_PATH, der als 260 Zeichen definiert ist. In späteren Versionen von Windows ist das Ändern eines Registrierungsschlüssels oder die Verwendung des Gruppenrichtlinie-Tools erforderlich, um den Grenzwert zu entfernen. -> Den hat der TE vor dem Kopieren bestimmt nicht gesetzt.

Ich habe nichts anderes behauptet. Aber du hast behauptet, dass darüber hinaus gehendes als Dateiendung bezeichnet wird. Daher habe ich erklärt, dass die Grenze von 260 Zeichen für das gesamte Konstrukt gilt und die Dateiendung mit da rein zählt.

• Es hat auch niemand behauptet, dass die überzähligen Zeichen abgeschnitten und als Dateiendung interpretiert werden. Behauptet wurde, das Punkte in Dateinamen je nach Betriebssystem als Beginn einer Dateiendung interpretiert werden.

Ähm. Doch. Genau das hast du behauptet. Warte, ich zitiere deinen Beitrag:

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.

• Weiterhin wurde damit behauptet, dass wirre Dateiendungen ein falsches Dateiattribut ergeben und sich durch den WINDOWS-Explorer nicht mehr eindeutig kopieren lassen.

Ja, das hast du behauptet, ist aber weiterhin falsch, weil du nicht verstanden hast, was Dateiattribute in diesem Fall bzw. überhaupt sind. Denn: Nein, die Dateiendung ist hier kein Dateiattribut und daher kann sie auch nicht der Verursacher sein.

• Die einzige Möglichkeit, eine solche nicht konforme Datei zu kopieren besteht wirklich darin, sie "einzuzippen" und ihr damit die ordentliche Dateienndung "zip" für den Kopiervorgang zuzuordnen.

Die Datei behält ihre Dateiendung auch im ZIP-Archiv. Sie ist halt nur gepackt. Auch das hat nichts mit Dateiattributen zu tun. Die Dateiattribute werden halt nur wie gesagt von Packprogrammen oft ignoriert und nicht mit eingepackt, zumindest in Standardeinstellung.

• Aus Sicht des Betriebssystems ist ein Dateiattribut eine Dateiendung, die einer Datei ein bestimmtes Anwendungsprogramm zuordnet, also z:B. png einem Grafikprogramm, txt einem Editor oder exe als ausführbares Programm. Wenn ein Programm wie Explorer also ein falsches Dateiattribut moniert, dann ist damit nicht das Dateiformat oder die Datei selbst gemeint, sondern eine falsche Dateiendung z.B. mit mehreren Punkten, die vom Betriebssystem nicht zugeordnet werden kann.

Nein! Die Dateiattribut ist nicht die Dateiendung! Daher hat es auch nichts mit Zuordnungen von Dateiendungen zu Programmen zu tun. Ja, eine Dateiendung kann keine Punkte beinhalten. Aber dann ist sie trotzdem nicht falsch. Es wird einfach nur das, was nach dem letzten Punkt kommt, als Dateiendung genommen. Du kannst ohne Probleme eine Datei t.e.s.t.png nennen. Ist dann halt eine PNG-Datei mit denm Namen t.e.s.t Ebenso kannst du auch eine Datei Test.p.n.g nennen. Ist dann halt eine G-Datei mit dem Namen Test.p.n - aber gültig ist auch das. Ist also trotzdem keine falsche Dateiendung. Und erst Recht kein falsches Dateiattribut, denn damit hat es nichts zu tun.

Nur kurz vorab zu @cuco - mit dir /r geht bei mir nichts. Hilfreich aber der Tip auf sysinternals. Ich habe mir streams gezielt downloaded und getestet. https://learn.microsoft.com/en-us/sysinternals/downloads/streams . Ich hänge einfach den ersten Test an, ein paar XXXX um den realen Namen zu löschen. Die .....property:$data schaue ich mir später an.

Danke für den Test!

Bisher hatte ich nur einen Vergleich, daß die Org-file-propertys und kopierte Nas-file properties unterschiedlich waren, aber im wesentlichen security etc., d.h. Zugriffsberechtigung. Die eigentliche Mail-file und die NAS-copy (backup) habe ich mit fileanalyzer verglichen - NAS ohne die ADS, aber die File selbst 100pro identsich, mit checksums und allem. D.h. für den eigentlichen Backup sind die ADS nicht nötig, weil die .eml inkl. Anhänge und ohne ADS ohne weitere Unterschiede im Mailer lesbar sind.

Das ergibt durchaus Sinn. Dateiattribute gehören eben nicht zum Inhalt der eigentlichen Datei. Klar kann man irgendwelchem "Schmu" machen und ganze Dateien in den Alternate Data Streams unterbringen - und sich wundern, warum die nach dem Klicke auf "nein" in deiner Meldung oder nach dem zippen weg sind, aber grundsätzlich wird die eigentliche Datei durch ADS nicht verändert, sondern eben nur um Zusatzinfos wie Berechtigungen erweitert. Die können für ein Backup erwünscht oder sogar nötig sein (weil z.B. sonst hinterher bestimmte User keinen Zugriff oder erst Recht (vorher verbotenen) Zugriff auf Dateien bekommen), aber die Datei selbst sollte auch ohne ADS vollständig und heile sein.

N:\tmp\xxxxxxxxxxxxx.eml:
:OECustomProperty:$DATA 16531

Interessant wäre jetzt, was in diesen ADS drin steht. Google sagt, Infos über Sender, Empfänger u.ä. der E-Mail, damit die Windows-Suche das leichter indexieren kann?

Nachtrag: dir /r funktioniert vom normalen "command prompt", nur nicht via "power shell", sorry, Peter

Ah, auch sehr interessant!

Oje, ich kann euch Profis da überhaupt nicht mehr folgen.

Sorry... ADS ist halt auch schon ein Thema "für Fortgeschrittene". Aber analog zum Test von albert66, der sich einfach nur die ADS seiner .eml-Dateien anschaut, wäre es bei dir noch interessant, den Test auch mal durchzuführen, um herauszufinden, welches Dateiattribut bzw. welcher ADS bei dir eben die Probleme macht.
Kannst du also mal eine Kommandozeile (cmd, nicht PowerShell, sonst geht es laut albert66 nicht) aufmachen und "dir /r" im Verzeichnis mit der "kaputten" .eml-Datei ausführen?

 

[albert66]

Unter https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc kann man sich die MS-Specs ansehen bzw. gleich (11MB) runter laden (linke Navi-Leiste "download PDF).

5.6.2 Outlook Express Properties Stream Name, Article, 02/14/2019
Outlook Express uses the stream name OECustomProperty for storage of custom properties related to email files.
The fully qualified form is sample.eml:OECustomProperty:$DATA.

Mozilla-Mailer (Seamonkey, Thunderbird) verwenden anscheinend die gleichen Specs, weil ich meine Mails auch problemlos im LAN in alten XP Outlook ansehen kann. Ich habe relativ viele Mails aus technischen Diskussionen archiviert, weil ich mir z.T. aus den Infos PDFs zusammen baue (i.d.R. Amateurfunk-Technik). Alle .eml haben bei mir diesen gleichen Streamnamen mit $DATA.

Für den Inhalt habe ich mir https://dmitrybrant.com/files/adsmanager.zip downloaded und mal nachgesehen. (Unpack, aufrufen, MS meckert /w "Unknown publisher", trotzdem ..... ) Test uploaded.Der Inhalt enthält die From-To Liste lesbar und einiges Hex-Kram (wenn man Hex anklickt bzw. den Export entsprechend ansieht). Ich vermute, daß hier die Mailer mit den Mail-Attributen (spam, junk, priority, .....) arbeiten und weiteres für's Adressbook interessante ablegen. Je nach Verteiler sind die ADS größer und kleiner, usw. Dazu müßte man intern in die Mailer.

Es gibt noch weitere ADS Tools, teste ich gelegentlich. Für die eigentliche Fehlermeldung des TO müßte ähnlich dem obigen sample.eml in dem fett gedruckten Teil etwas schief gelaufen sein. Evtl. falsche oder unzulässige Streamnamen (s. openspecs) oder Syntaxfehler. Evtl. per dir /r (cmd-line) erkennbar. Möglicherweise hat der NAS (je nach Speicherformat) den Name auch verkürzt oder "verbogen". Sollte dann mit der streams-option -d evtl. komplett löschbar sein. Vermutlich legt der Mailer nach Restore/Aufruf ohne ADS gleich wieder neue ADS-Info an. Bei mir ist jedenfalls beim Hin- und Her-Schaufeln inkl. direktem Aufruf (mit und ohne ADS) an den Mails nichts aufgefallen.

OT: Ich werde jedenfalls bei mir gründlich im Win zur ADS-Geschichte nachfassen. Mir ist vom OS/2 z.B. geläufig, daß der REXX-Interpreter den REXX-Source in pseudo-code umwandelt und in EA (extended Attributes) speichert. Dieser EA-Code wird dann executed(interpretiert). Man kann den Löschen, no problem, macht er bei nächsten Aufruf wieder neu. Läßt man die EA leben, ist die 2. Ausführung schneller (pseudo-code Generierung fehlt). Das jetzt nur mal als Beispiel, wofür diese Anhängsel auch produktiv verwendet werden. Natürlich ein gefundenes Fressen für Hacker. Mein Thinkpad, der öfter mal am Hotel-WLAN hing, hat jedenfalls die nächsten Wochen nichts zu lachen, .... ADS-Digging aus allen Rohren.

Gruß Peter

Nochmal Nachtrag: ich sehe eigentlich zum Backup bei .eml mit ADS keine großen Sinn. Die sind ja nicht mit der Mail gesendet und eingelesen worden. Fall die später restored werden, sind in dem dann benutzten Mail-Programm vermutlich neue Bedingungen. Die eigentlich früher gesndete Mail-Information ist ja nach wie vor komplett vorhanden. D.h. .eml auf dem Backup braucht ADS so nötig wie einen Kropf .

Nachtrag Testfile-Info

dir n:\tmp\xx*.eml /r
Volume in drive N is n-arc
Volume Serial Number is 3E8B-10E4
Directory of n:\tmp
29.09.2022 10:43 38,750 xxxxxxxxxx - Copy.eml
16,531 xxxxxxxxxx - Copy.eml:OECustomProperty:$DATA
1 File(s) 38,750 bytes