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?

  • TB hat Probleme mit sehr großen Mail-Ordnern. Vielleicht ist da was kaputt gegangen.

  • 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.

  • 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.

  • 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.



    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.

  • Ich darf widersprechen

    Selbstverständlich. Davon leben Diskussionen.

    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.


    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.


    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-…eIO/naming-a-file#maxpath

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

    Einmal editiert, zuletzt von Solaris () aus folgendem Grund: Hatte aus Versehen bereits während des Schreibens gespeichert.

  • 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.

    Hallo :)


    jein. Es gib zwei Methoden, siehe dazu Maximum Path Length Limitation. Der Windows Explorer beachtet MAX_PATH, die andere Anwendung hat das in Deinem Beispiel nicht getan. Das ist aber weniger ein Problem, und schon gar kein Bug in Windows, sondern dokumentiertes Verhalten.


    Gruß Ingo

  • 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

  • Hallo Systemanalytiker,


    die maximale Pfad- bzw. Dateinamenslänge solltest du als gegebenen Fakt nehmen, denn daran können weder du noch wir etwas ändern.


    Beim "Speichern unter" wird die Mail im von dir festgelegten Ablagepfad und mit dem von dir gewählten Dateinamen abgespeichtert. Wenn du damit öfters auf die maximale Länge stößt, hast du entweder eine recht tiefe Ordnerstruktur und/oder lange Ordnernamen (in dieser Ordnerstruktur) und/oder recht lange Namen für die EML-Datei. Das sind gleich 3 Ansatzpunkte, die man genaer betrachten und ggf. verändern kann, um künftig ohne solche Probleme abzuspeichern.


    Dass Thunderbird daran nichts verändern kann, weil es eine Einschränkung des Betriebssystems ist, schrieb dir bereits Solaris.


    MfG

    Drachen

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

  • Ich darf zwecks Vermeidung von Wiederholungen auf mein Post #38 ... verweisen.

    Den hatte ich gesehen, der zäumt das Pferd aber von hinten auf und macht dir mittel- und langfristig sogar mehr Aufwand.

    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.


    MfG

    Drachen

  • ...

    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.


    "...

    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.

  • Hallo,


    prima. Auf die vorgeschlagenen (!) Dateinamen wäre ich sonst als Nächstes eingegangen, je nach Betreff der Mail können die nämlich lang werden, zumal sie wie von dir erwähnt noch um Datum und weitere Angaben ergänzt werden. Den Effekt hast du auch bei anderen Programmen, Word beispielsweise nimmt die erste Überschrift eines Textes als Vorschlag für den Dateinamen.

    Mit der eigenen Änderung des Namens abweichend vom Vorschlag bist du automatisch wieder beim von mir vorgeschlagenen Namensschema, um welches du dir so oder so Gedanken machen musst ;-)


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


    MfG

    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"?

  • Hallo,

    Es ist nicht mein Problem.

    Es ist ein Problem von Thunderbird.

    ....

    Das Problem liegt bei Thunderbird. Sicher nicht bei mir.

    Da du das Gegenteil bereits selber bestätigt hast, müssen wir das m.E. nicht mehr weiter diskutieren. Und so wie du das Mantra-artig wiederholst, ist dir das inzwischen wohl auch selber klar.

    (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. Es wäre viel ärgerlicher, wenn TB bei jedem Speichern immer nur "mail.msg" o.ä. vorschlagen würde, bei deinen 95.000 Mails würde das selbst bei automatischer fortlaufender Nummerierung (je Unterordner) ein interessantes Chaos.


    Aber auch hier sind die Geschmäcker verschieden, daher kann es hier kein absolutes "richtig!" oder "falsch!" geben. Für meine private Arbeitsweise ist es beispielsweise unnötig bis sinnlos, jede Mail nochmal zusätzlich als EML oder MSG zu exportieren, auf Arbeit speichere ich dagegen durchaus alle paar Wochen oder Monate mal eine Mail (von den ca. 3 bis 5 Dutzend täglich) als MSG-Datei. Du hingegen willst gleich knapp 100.000 Mails derart exportieren. Wie gesagt, die Anforderungen und Wünsche sind verschieden.

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

    Hat das hier jemand behauptet? Nein.


    Ich kenne das Problem mit langen Betreffzeilen durchaus, bekomme auf Arbeit immer wieder mal Mails von Leuten, die ganze Problembeschreibungen inkl. Grußfloskeln komplett in mehrzeilige Betreffzeilen werfen, den Body der Mail aber nicht nutzen, so wie hier im Forum hin und wieder Leute ganze Problembeschreibungen mit oder ohne Höflichkeitsfloskeln als Betreff neuer Thread reinschreiben (was Mods oder Admin erfreulicherweise meist sehr zügig ändern).


    Solch einen (zu) langen Betreff aber nicht als Dateinamen zu verwenden, darauf hat jeder Anwender durchaus Einfluss, du ebenfalls.

    Da ich dich als lernfähig und vermutlich sogar wissbegierig einschätze, weißt du wie oben schon erwähnt meiner Meinung nach inzwischen auch, wie es zu den völlig korrekten Meldungen kam und was du dagegen tun kannst und musst.

    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.

    Das Programm kann nicht entscheiden, welcher Teil des ggf. zu langen Betreffs relevant ist und welcher nicht. Es könnte bestenfalls einfach abschneiden und damit mit ca. 50%er Wahrscheinlichkeit den Sinn verstümmeln und damit den Dateinamen mangels Aussagekraft wertlos machen. Wenn du ein wenig darüber nachdenkst, dann wirst du wohl zur selben Ansicht kommen, nämlich dass das definitiv nicht besser wäre und eine selbständige "automatische" Lösung durch ein simples Mailprogramm nicht möglich ist. 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 ....

    Wo setzt man den Label "Erledigt"?

    Oben über deinem ersten Beitrag des Threads ist so ein kleines Kästchen für "erledigt" o.ä., das kreuzt du einfach an.


    Schönen Restsonntag noch :)

    Drachen

  • 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?)


    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?

    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.