Speichern unter in ein Verzeichnis auf der Festplatte funktioniert nicht

Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

• Thunderbird-Version: 52.7.0 (32 bit)
• Betriebssystem + Version: Windows 10 Pro April Update (64 bit)
• Kontenart (POP / IMAP): POP
• Postfach-Anbieter (z.B. GMX): yahoo
• Eingesetzte Antiviren-Software: Norton Security (aktuell)
• Firewall (Betriebssystem-intern/Externe Software): Norton Security (aktuell)
• Router-Modellbezeichnung (bei Sende-Problemen):

Wenn ich in einem Thunderbird Ordner (lokal) alle E-Mails - ca. 20.000 - mit String A markiere und diese versuche mit "Speichern unter" auf eine Festplatte (USB NTFS - Festplatte OK) zu speichern, dann erscheint nach 1.300 Mails die Meldung "Kann Nachricht nicht speichern. Bitte überprüfen Sie den Dateinamen und versuchen Sie es später nochmals."

Der Kopiervorgang wird abgebrochen. Der angeblich "kaputte" Dateinamen wird nicht angezeigt.

Ist der Thunderbird bzw. Windows 10 Pro - Bug bekannt?

Bei bei meinen Daten ist alles in Ordnung. Mit dem Addon ImportExportTools funktioniert auch alles.

Aber das "Speichern unter" ist eine TB Funktion, die nicht ganz funktioniert.

Ich vermute folgende Konstellation: Thunderbird verwendet eine falsche Windows API, die

dann zu einem Speicher(n)Problem führt.

Es ist ein Thunderbird-Bug, der nicht vielen Usern auffällt, weil

das Addon ImportExportTools ohnehin funktioniert.

Was immer eine falsche API sein soll, ein Fehler in einer so elementaren Schnittstelle im Windows kann realistisch gesehen nahezu ausgeschlossen werden.

Die Erweiterung ImportExportTools läuft unter verschiedenen Betriebssystemen. Deshalb darf unbesehen angenommen werden, dass diese für die Dateioperationen die Funktionen des Thunderbird nutzt.

Zitat von Solaris

Was immer eine falsche API sein soll, ein Fehler in einer so elementaren Schnittstelle im Windows kann realistisch gesehen nahezu ausgeschlossen werden. ...

Ich darf widersprechen. Andererseits muss ich festhalten, dass das Wort "falsch" nicht ganz passt. "Schlechte Windows-API" wäre besser.

Das kann eben nicht ausgeschlossen werden.

Regelmäßig wenn ich meine Daten sichere, spuckt der Windows Explorer Fehlermeldungen "Dateiname zu lang..." "Pfad zu lang..." aus.

Da wird dann argumentiert, dass diese Konstellationen nicht den "Windows-Spezifikationen" entspricht. Windows lässt nur 256 Byte .... zu.

Das kann nicht stimmen, weil alle meine Daten ausschließlich unter Windows erstellt wurden. Wie können dann Dateinamen, die länger als 256 Byte sind, entstehen? Weil die betroffenen Programme eine "andere Windows-API" bzw. eine "besondere Windows-API" verwenden.

Ähnlich sehe ich das bei Thunderbird. Bei der "Speichern unter .... " Funktion übergibt Thunderbird die Daten an eine Windows-API, die mit den übergebenen Daten nichts anfangen kann. Dann kommt es unter Windows (nicht unter Thunderbird) zu der Fehlermeldung wie von mir in meinem ersten Beitrag gepostet und bricht den Vorgang komplett ab.

Zitat von graf.koks

Zitat von Systemanalytiker

Thunderbird verwendet eine falsche Windows API, die

dann zu einem Speicher(n)Problem führt.

Mag sein, ich würde halt erstmal schauen ob sich das mit einer Teilmenge der 20000 Mails anders verhält. Wär ja ein einfacher Versuch.

Danke für den Tipp. Meine lokalen Ordner haben mehr als 20000 Mails aber weniger als 4 GByte. Ich werde das bei gegebener Zeit testen.

Zitat von Systemanalytiker

Ich darf widersprechen

Selbstverständlich. Davon leben Diskussionen.

Zitat von Systemanalytiker

Andererseits muss ich festhalten, dass das Wort "falsch" nicht ganz passt. "Schlechte Windows-API" wäre besser.

Das kann eben nicht ausgeschlossen werden.

Ausschließen kann ich Fehler in der API nicht. Gerade die API für I/O ist aber so elementar und wird täglich tausende Male auf jedem Windows-Rechner weltweit benutzt, dass schwerwiegenden Fehler praktisch ausgeschlossen sind. Ohne fehlerfrei funktionierendes I/O wäre ein Betriebssystem nutzlos.

Deine Argumentation enthält ferner einen Fehler, der die Frage nach der API obsolet macht. Aus dem bereits weiter oben genannten Grund gehe ich davon aus, dass die ImportExportTools dieselbe API nutzen wie der Thunderbird. Genauer: Sie nutzen die Routinen des Thunderbird, der wiederum die API des Betriebssystems nutzt.

Unter dieser Voraussetzung kann die Ursache also nicht in einer Windows-API liegen, denn es wird in beiden Fällen dieselbe benutzt.

Der Umstand, dass die ImportExportTools keinen Fehler melden, muss eine andere, mir nicht bekannte, Ursache haben.

Zitat von Systemanalytiker

Regelmäßig wenn ich meine Daten sichere, spuckt der Windows Explorer Fehlermeldungen "Dateiname zu lang..." "Pfad zu lang..." aus.

Dann hast du ein schwerwiegendes Problem, das außerhalb des Thunderbird liegt, bisher einfach ignoriert. Unter diesen Umständen von einem Bug in Windows oder Thunderbird zu sprechen, ist zumindest verfrüht.

Zitat von Systemanalytiker

Da wird dann argumentiert, dass diese Konstellationen nicht den "Windows-Spezifikationen" entspricht. Windows lässt nur 256 Byte .... zu.

Das kann nicht stimmen,

Doch, das ist korrekt. Es nur weitaus komplexer als du es dir vielleicht vorstellst. Neben der absoluten Länge spielen viele weitere Faktoren hinein, ich nenne beispielhaft nur die symbolische Links.

Außerdem gibt es einen Unterschied zwischen dem Dateisystem (und somit der API) und der Shell (z.B. dem Explorer). Über die API lassen sich Pfade anlegen, die von der Shell nicht verstanden werden.

Wenn du dazu mehr wissen willst, lies bei Microsoft nach: https://docs.microsoft.com/de-de/windows/…-a-file#maxpath

Dort findest du auch die Bestätigung, dass 256 (= 260 - 4) die normale Obergrenze ist.

Das ist der gleiche Artikel, den ich bereist oben genannte hatte.

Danke für alle Zusatzinfos und Links. Wir haben jetzt diverse Begriffe wie API, Shell, MaxPath, ...

Man kommt der Sache etwas näher.

Ich vermute Thunderbird konvertiert eine E-Mail bei "Speichern unter ..." in eine EML-Mail und übergibt die Daten dem Windows-Explorer. Dies mit gesetzten oder nicht gesetzten Parametern, die zum "dokumentierten Verhalten" führen, nämlich zum Abbruch der Speicherung der weiteren E-Mails. Es handelt sich in einem solchen Fall um ein "dokumentiertes Verhalten", das ich als unerwünscht betrachte. Ein "Design-Fehler". Thunderbird müsste entweder "direkt" speichern mit den entsprechenden APIs oder dem Windows-Explorer den richtigen "Max-Path" oder ähnliches "übergeben".

Es wäre schön, wenn Thunderbird diese "Design-Irritation" behebt. Spätestens dann, wenn das ADDON importexporttools nicht mehr gewartet wird. Es bleibt noch Zeit, da derzeit das ADDON noch gepflegt wird.

https://freeshell.de/~kaosmos/index-en.html

Ich darf zwecks Vermeidung von Wiederholungen auf mein Post #38 in

Ordner Komprimieren - 89321 GB - was soll das sein?!?

verweisen.

Deine Thesen werden mir jetzt ehrlich gesagt zu abstrus. Darauf mag ich nicht weiter eingehen. Eine gewisse Vorahnung hatte ich schon.

Zitat von graf.koks

...

Mag sein, ich würde halt erstmal schauen ob sich das mit einer Teilmenge der 20000 Mails anders verhält. Wär ja ein einfacher Versuch.

...

Ich habe es jetzt konkret mit einem lokalen Ordner mit knapp 17.000 E-Mails probiert. Ich erhalte die gleiche Meldung nach cirka 4.500 gespeicherten E-Mails "..... überprüfen Sie den Dateinamen ...".

An der Teilmenge liegt es somit nicht.

Zitat von Drachen

"...

Wenn du dir von vornherein mehr Gedanken über Ordnertiefe und die Länge von Ordnernamen und Dateinamen, also eine für dich optimale Ordnerstruktur und Namensschema machst, musst du hinterher auch nicht mit zusätzlicher Software zu lange Namen kürzen, was erfahrungsgemäß wieder andere Probleme verursacht.

... "

Stimme grundsätzlich zu. Ich kann mir aber nur dort Gedanken machen, wo ich einen Einfluss habe.

Ich habe die "Speichern unter ..." Funktion nochmals getestet. Die Quelldateien sind sauber, also weit unter der 256 Byte Problematik. Der Zielordner beträgt 10 Stellen und liegt direkt auf dem Laufwerk C (nur zum Testen).

Ich bekomme wieder dieselbe lapidare Fehlermeldung

"Kann Nachricht nicht speichern. Bitte überprüfen Sie den Dateinamen und versuchen Sie es später nochmals."

Der von Thunderbird erzeugte Dateinamen setzt sich aus dem Betreff verschiedenen Datumsfeldern und andere Zusätze zusammen.

Die von Thunderbird produzierten langen Dateinamen stammen nicht aus meiner Sphäre.

Das Problem - welche Ursache es auch immer hat - liegt bei Thunderbird.

EDIT: "Ich habs - Hurra!

Ich hab die Lösung. Dank für Eure Mithilfe.

Die von Thunderbird bei der Verwendung der "Speichern als..." Funktion erzeugten Dateinamen sind eindeutig zu lange.

Ich hab ein Bild als Dateianhang zur Verfügung gestellt.

Der Beweis sozusagen.

Zitat von Drachen

"... Prinzipiell ist dein Problem damit gelöst, denke ich. ..."

Es ist nicht mein Problem.

Es ist ein Problem von Thunderbird.

Ich werde mir bei 95.000 E-Mails sicher keine Gedanken über die Namenslänge bzw. Namensgebung machen.

Das muss schon die Export-Funktion "Speichern unter" selbst automatisch lösen.

Bei der Menge an E-Mails ist das manuell schlicht und einfach nicht machbar.

Dazu kommt, dass ich auf die Länge der Betreffzeilen von E-Mails, die ich empfange, überhaupt keinen Einfluss habe.

Das Problem liegt bei Thunderbird. Sicher nicht bei mir.

"Erledigt" ist das Thema für mich, weil die fehlerhafte Funktion "Speichern unter" nicht sinnvoll verwendbar ist.

Wo setzt man den Label "Erledigt"?

Es ist zunächst einmal gut, dass damit die irreführenden Thesen von der "falschen" oder "schlechten" API und dem Explorer vom Tisch sind.

Hier zeigt sich meiner Meinung nach gut, dass etwas, das auf den ersten Blick geradezu trivial erscheint, in der Detailbetrachtung für den Programmierer erhebliche Hürden enthalten kann, die man bedenken sollte, bevor man voreilig einen "Schuldigen" ausmacht. (Hier im Wechselspiel Thunderbird, die Windows-API, Windows/NTFS, der Explorer und nun wieder der Thunderbird. Wer fehlt?)

Zitat von Systemanalytiker

Es ist ein Problem von Thunderbird.

Dem stimme ich in der Sache zu, möchte aber etwas zu bedenken geben.

Irgendeinen Dateinamen muss der Thunderbird vergeben bzw. vorschlagen, will man ihn nicht von Hand eingeben. Die einfachste Lösung wäre eine Numerierung. Das würde der Mehrheit der Benutzer gewiss nicht gefallen.

Entscheidet man sich für den Weg, den Betreff zu verwenden, tauchen mehrere Schwierigkeiten auf.

Um nur ein paar Beispiele zu nennen: Abgesehen von der Länge, kann ein Betreff Zeichen enthalten, die für einen Dateinamen nicht erlaubt sind. Diese Zeichen können sich je nach Dateisystem unterscheiden. Man bedenke auch das unterschiedliche Verhalten bei Groß- und Kleinschreibung.

Unterschiedliche Betriebs- und Dateisysteme können auch gleichzeitig zum Einsatz kommen, vielleicht nur, weil jemand auf einen FAT32-Stick speichern möchte.

Die Systeme können auch noch unterschiedlich konfiguriert sein, siehe die Möglichkeit, die 256-Zeichen-Grenze unter NTFS/Windows zu überwinden.

Technisch wäre das alles handhabbar, erfordert jedoch mehr Aufwand, als es zunächst scheint. An dieser Stelle stellt sich die Frage nach Aufwand und Nutzen. Wie viele Benutzer betrifft das Problem? Wie oft und für welchen Anwendungsfall tritt es auf? Ist der Anwendungsfall kritisch oder hat der Anwender Alternativen?

Zitat von Systemanalytiker

Es ist nicht mein Problem.

Zumindest die Aufgabenstellung, nämlich eine große Anzahl E-Mails lokal zu speichern oder zu archivieren, ist eine Anforderung von dir für dich. Nach meinem Dafürhalten ist somit auch die Lösung primär dein "Problem".

Wenn die von dir gewählten Methode nicht funktioniert, dann bedenke andere Optionen. Es gibt eine Vielzahl an Möglichkeiten, mit ihren Für und Wider.

Das kann ein anderes E-Mail-Programm sein oder auch einfach nur ein anderes Format für die Archivierung. Man kann die Mboxen archivieren oder auf Maildir umstellen. Man kann auch ein zusätzliches Archivierungsprogramm verwenden.

Das wären Optionen, die dich deinem Ziel näherbringen. Diese Dinge hast du selbst in der Hand. Das ist besser als vermeintliche Unzulänglichkeiten aufzulisten, auf die du keinerlei Einfluss hast.

Zitat von Drachen

...

Länge stupide nach Zeichenzahl kürzen ginge automatisch, aber die Länge sinnvoll kürzen geht (noch!) nur manuell. In 20 Jahren hast du vielleicht eine KI eingebaut, die das für dich übernehmen kann, vielleicht auch erst in 50 Jahren

....

Auf künstliche Intelligenz braucht man nicht 50 Jahre warten.

Eine E-Mail im Maildir-Format enthält die Betreffzeile nicht im Original im Dateinamen.

Der angefügte Dateianhang enthält einen Screenshot einer Mairdir-Datei, wobei ich

manuell auf .eml umgestellt habe.

Ähnlich macht es der Converter Aid4Mail MBox Converter.

Zitat von Solaris

Wenn die von dir gewählten Methode nicht funktioniert, dann bedenke andere Optionen. Es gibt eine Vielzahl an Möglichkeiten, mit ihren Für und Wider.

Das kann ein anderes E-Mail-Programm sein oder auch einfach nur ein anderes Format für die Archivierung. Man kann die Mboxen archivieren oder auf Maildir umstellen. Man kann auch ein zusätzliches Archivierungsprogramm verwenden.

Das wären Optionen, die dich deinem Ziel näherbringen. Diese Dinge hast du selbst in der Hand. Das ist besser als vermeintliche Unzulänglichkeiten aufzulisten, auf die du keinerlei Einfluss hast.

ad "vermeintliche Unzulänglichkeit": Es stimmt, dass die Behebung des Problems der 256 Byte Begrenzung, das im übrigen vielen Nutzern Kopfzerbrechen bereitet wenn man dazu googelt, ein programmiertechnischer Aufwand ist. Bei einer Non-Profit-Organisation wie Mozilla habe ich dazu auch eine hohe Frustationstoleranz. Bei Microsoft, einem Technologiegiganten, sehe ich das differenzierter. Für mich und andere Nutzer ist es ärgerlich, wenn während eines Kopiervorganges der Kopiervorgang lapidar abbricht mit dem Hinweis "Dateiname ist zu lang" ohne anzugeben welche Datei konkret überhaupt gemeint ist.

ad "Alternativen": Da stimme ich Dir zu. Nach einigen Recherchen bin ich zum Schluss gekommen, dass ich die technischen Unzulänglichkeiten mit "Mailstorehome" und "Aid4Mail Mbox Converter" "umschiffen" kann. Das hat aber seine Zeit gedauert, bis man das entsprechende Know-How erarbeitet hat.

Zitat von Drachen

...

(Fast) Jedes Programm macht beim Speichern irgendwelche Vorschläge für Dateinamen - wenn Anwender diese nicht lesen, sondern einfach nur auf OK klicken, kann man das nun wirklich nicht als ein Problem des Programms oder gar als fehlerhafte Funktion bezeichnen.

...

Wenn ich mit String A mehrere E-Mail unter Thunderbird markiere und danach Speichern unter aktiviere, dann schlägt Thunderbird keine Dateinamen vor, die man eventuell kürzen könnte. Die markierten E-Mails werden im Batch-Mode im .eml-Format abgespeichert.

Zusammenfassung: Ich bedanke mich für alle konstruktiven und sachlichen Beiträge. Derzeit mit dem MBOX Format habe ich einen brauchbaren Workflow gefunden. Ich hoffe ich absehbarer Zukunft auf MAILDIR umsteigen zu können und ebenfalls einen brachbaren Workflow zu finden.