in TB lassen sich Anhänge nicht öffnen

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

    • Thunderbird-Version:68.3.1 (32-Bit)
    • Betriebssystem + Version: Windows 10 Home
    • Kontenart (POP / IMAP): POP
    • Postfachanbieter (z.B. GMX): GMX
    • Speicherdienst (z.B. Dropbox):
    • Eingesetzte Antivirensoftware: Kaspersky
    • Firewall (Betriebssystem-intern/Externe Software): Betriebssystem-intern

    In diesem Thread wurde ein Problem geschildert, das ich auch habe.


    Es geht darum, dass TB beim Öffnen und Senden Probleme mit Anhängen hat.

    Das Öffnen der Anhänge aus Thunderbird heraus klappt nicht, auch das Versenden eines Anhanges - beide Probleme treten aber nicht immer auf.


    Manche Anhänge kann ich aus der Email heraus öffnen, egal welches Format (pdf, docx).

    Andere wiederum kann ich nicht direkt in Thunderbird öffnen, über die Speicherfunktion geht es aber.


    Bei Worddateien lautet die Fehlermeldung:

    "Diese Datei wurde nicht gefunden. (C:\Windows\System32\2020.docx)" wobei die Kennung vor dem .docx immer nur ein Teil des Dateinamens der Datei ist, die ich öffnen möchte.


    Bei PDFs erhalte ich nur:

    "Beim Öffnen dieses Dokuments ist ein Fehler aufgetreten. Diese Datei kann nicht gefunden werden."


    Beim Versenden ist das Problem auch nicht einheitlich. Habe ich die Datei angehängt und möchte sie vor dem Versenden öffnen, erhalte ich die Fehlermeldung, dass die Datei nicht verfügbar sei mit dem Verweis auf dem Windows-Ordner System 32.


    In dem anderen Thread wurde schon diskutiert, ob Leerzeichen in den Dateinamen ein Problem sind. Ich habe nochmal ausprobiert:


    Beim Versenden von Word- oder PDF-Dateien, die ein Leerzeichen im Dateipfad (nicht nur im Namen) haben, erfolgt die Fehlermeldung.

    Beim Versenden von Word- oder PDF-Dateien, die kein Leerzeichen im Dateipfad haben, erhalte ich keine Fehlermeldung.

    Das gleiche Phänomen stellt sich beim Empfangen.


    Ich habe mal eine Textdatei mit dem Editor erstellt und "Test1" und "Test 1" genannt. Hier klappt das Öffnen in TB ohne Probleme. Dasselbe habe ich mit zwei Worddateien versucht ("Test1" und "Test 1") und hier hat nur das Öffnen der Datei ohne Leerzeichen geklappt.

    Beim Öffnen der Datei mit Leerzeichen erhielt ich folgende Fehlermeldung:

    'R:\SJ1213\Test' kann nicht gefunden werden. Überprüfen Sie die Rechtschreibung , oder verwenden Sie einen anderen Pfad."

    Als ich auf "Ok" klickte, kam darauf sofort eine weitere Fehlermeldung:

    'R:\SJ1213\1' kann nicht gefunden werden. Überprüfen Sie die Rechtschreibung , oder verwenden Sie einen anderen Pfad."


    TB scheint also aufgrund des Leerzeichen nach zwei unterschiedlichen Dateien zu suchen.


    Wobei mir unklar ist, warum es bei *.txt-Dateien keine Rolle spielt.

    Quote from Papewaio

    In dem anderen Thread wurde schon diskutiert, ob Leerzeichen in den Dateinamen ein Problem sind. Ich habe nochmal ausprobiert:


    Beim Versenden von Word- oder PDF-Dateien, die ein Leerzeichen im Dateipfad (nicht nur im Namen) haben, erfolgt die Fehlermeldung.

    Beim Versenden von Word- oder PDF-Dateien, die kein Leerzeichen im Dateipfad haben, erhalte ich keine Fehlermeldung.

    Hallo :)


    das bestätigt meine Vermutung aus #15. Allerdings scheint es nicht so einfach wie von mir in #5 geschildert zu sein, sondern, wie von Mapenzi in #11 erwähnt, ein Bug in TB. NumLock hat meine Vermutung in #21 übrigens bestritten. Er kann Dir sicher genau sagen, woran es liegt und wie Du es beheben kannst.


    Gruß Ingo

    Hallo Ingo,


    was mich weiterhin irritiert ist, dass es bei Word- und PDF-Dateien ein Problem darstellt, wenn ein Leerzeichen dabei ist, aber bei den *.txt-Dateien unerheblich zu sein scheint.

    Ich hoffe mal auf das nächste Update.


    Gruß

    Pape

    Hier beschreibt ein User, dass er die handlers.json umbenannt hatte und dann die von ihm dargestellten Probleme nicht mehr auftraten. Es sind nicht exakt die gleichen wie bei mir, aber ich habe es mal ausprobiert. Hat auch keinen Erfolg gebracht.

    Quote from schlingo

    das bestätigt meine Vermutung aus #15.

    Nein, das tut es nicht. Du verstehst anscheinend dein eigenes Geschreibsel nicht. In deinem Beitrag geht es zwar korrekterweise um das Maskieren von Leerzeichen, jedoch bei (editierbaren) Verknüpfungen. Um die geht es hier aber nicht! Deshalb kann man das auch nicht selbst korrigieren und auch nicht durch Libre Office oder irgendwelche Registry Einträge. Und deshalb sind deine Beiträge ärgerlich, weil du andere ermunterst, ohne Grund an ihrem Windows zu doktern.


    Lies dir den Bug durch, den Mapenzi gefunden hat. Das Maskieren erfolgt durch den Thunderbird und funktioniert laut Bug nicht mehr richtig. Es ist ein Bug im Thunderbird.

    Unklar ist, weshalb der Fehler scheinbar zufällig auftritt. Bei den einen funktioniert alles bei anderen manchmal nicht. Bei manchen scheint es gar vom Dateityp abzuhängen. Klar ist aber: Der Fehler liegt nicht im Windows, nicht im Libre Office und auch nicht in der Registry.

    Ich würde dazu auch mal die Einstellung zum Virenschutz überprüfen, also die, ob der Thunderbird es ermöglichen soll, Nachrichten unter Quarantäne zu stellen.

    Quote from schlingo

    Er kann Dir sicher genau sagen, woran es liegt und wie Du es beheben kannst.

    Er ist eine Sie und kann selbstverständlich das wiederholen, was die Entwickler im Bug geschrieben haben. Wer von dem Bug betroffen ist muss auf die 68.4 mit dem Fix warten. So einfach ist das.

    Quote from Papewaio

    Beim Versenden ist das Problem auch nicht einheitlich. Habe ich die Datei angehängt und möchte sie vor dem Versenden öffnen, erhalte ich die Fehlermeldung, dass die Datei nicht verfügbar sei mit dem Verweis auf dem Windows-Ordner System 32.

    Wenn du sie aus der Mail heraus öffnen willst, dürfte der bekannte Bug zuschlagen. Der Dateiname wird nicht richtig maskiert an die zuständige App gesendet.

    Hallo,


    mich irritiert ein anderes Detail:

    Quote from Papewaio

    Bei Worddateien lautet die Fehlermeldung:

    "Diese Datei wurde nicht gefunden. (C:\Windows\System32\2020.docx)"

    Datendateien von Anwendern haben in Systemordnern rein garnichts zu suchen und normalerweise haben normale Konten dort auch keine Schreibrechte. M.E. ist hier also schon in Windows irgendetwas ganz fürchterlich verstellt, vermutlich (unter Anderem, aber sehr wahrscheinlich nicht nur) der Inhalt der Systemvariablen TEMP (und TMP). Der verweist normalerweise auf den Pfad C:\Users\%username%\AppData\Local\Temp und nie auf C:\Windows\System32\.


    MfG

    Drachen

    [halb OT]Hallo NumLock,


    ich verstehe deine Antwort nicht. "nicht maskiert" heißt doch, dass Klartext kommt und die mich irritierende Angabe den Tatsachen entspräche - womit meine Bemerkung eher unterstützt als relativiert würde. Wie gesagt, ich verstehe nicht, was du mir sagen willst.


    MfG

    Drachen[/halb OT]

    Die gute Nachricht lautet: Der Bug ist gemäß Bugzilla gefixt!


    Was dann noch so eine Schattendiskussion soll, muss ich nicht verstehen, oder? Klar ist doch, es handelt sich um einen Bug im Thunderbird. Nachzulesen hier: https://bugzilla.mozilla.org/show_bug.cgi?id=1601905 . Dort steht unter anderem


    Quote from Toshihito Kikuchi

    This caused a regression that if a filepath contains whitespaces, we pass it to a target application without quoting it ...


    Interessant auch

    Quote from Jorg K

    Frankly, I'm on TB 68.3.1 where the bug is not fixed so far and I've never experienced it despite opening attachments left, right and centre. But it only affects certain applications; I can open PDFs with spaces in their name with PDF XChange Viewer with no problem ... EDIT: And .odt and .doc(x) in LibreOffice (EDIT 2: version 5.4) and images in Windows Photo Viewer.


    Dies bestätigt, dass der Fehler nicht bei jedem auftritt/-trat. Bei mir funktionierte das auch stets einwandfrei.

    Warum taucht nun im Pfad system32 auf? Ich vermute, das ist eine unmittelbare Folge des Bugs. Unter System32 liegt die Komponente, die innerhalb Windows aufgerufen wird, wenn ein Programm ein anderes starten oder ihm Daten übergeben möchte. Ähnlich, wie es bei OLE oder früher DDE war. Irgendein Windows Dienst/Server muss das ja erledigen. Selbst wenn die Benachrichtigung an das Programm über COM stattfinden würde, ginge es nicht ohne die zugehörige Windowskomponente.