Hilfe durchsuchen

Vorsicht vor Support-Betrug: Wir fordern Sie niemals auf, eine Telefonnummer anzurufen, eine SMS an eine Telefonnummer zu senden oder persönliche Daten preiszugeben. Bitte melden Sie verdächtige Aktivitäten über die Funktion „Missbrauch melden“.

Learn More

Problem opening attachments of Word documents with spaces in the filename

  • 31 Antworten
  • 9 haben dieses Problem
  • 80 Aufrufe
  • Letzte Antwort von gglazer

more options

Since the upgrade to 68.3, my wife can no longer open attachments of Word documents (docx) whose filename contains blank spaces (e.g. File name.docx). The error message popups indicate that Word is trying to open a different document with each word in the filename. So, in the above case it tries to open a document named File.docx, fails, and the another document named name.docx and also fails. Oddly, this is limited to Word files. Similarly named PDFs and PowerPoint files work fine.

The temporary files created when I attempt to open the offending attachments are saved with the proper folder. I can find them in the Tools->Saved Files, and the full file names appear. Attempting to open them through Thunderbird results in the same error. However, selecting the Open Containing Folder, and then double-clicking them from there (taking Thunderbird out of the loop) works as it should.

I've tried safe mode, but that did not fix the problem. She can forward the email to me, and I can open it on my laptop.....using version 68.3. If I replace the spaces with underscores and ship the file back to her, it opens without incident. The settings on our installations are the same, both using Windows 10, both with Word 2016.

I've tried repairing the folder (Inbox), compacting, and even deleting the msf file so it could be rebuilt, but the problem persists.

In scanning the database, I found an old problem that is similar: content-disposition filename cut (truncated) at space. That problem was resolved 16 years ago. As best as I can tell, that problem involved saving the file, whereas in this case the temporary files are being saved correctly, but Word is being told to open a file with only the portion of the name until the space, and then additional files between the spaces.

I tried reinstalling 68.3, but got the same results. I rolled her back to 68.2.2 and restoring a profile from the day before the upgrade, and everything works as it should.

There is nothing peculiar about her configuration. The only thing not by default is her email data (not the profile) is stored in a separate partition on her SSD, a D partition devoted to data storage only.

Disabling the internet security did not help. Since the email data was unchanged in the restore process, the problem does not lie in the data file.

Any suggestions?

Configuration details are available, if needed.

Since the upgrade to 68.3, my wife can no longer open attachments of Word documents (docx) whose filename contains blank spaces (e.g. File name.docx). The error message popups indicate that Word is trying to open a different document with each word in the filename. So, in the above case it tries to open a document named File.docx, fails, and the another document named name.docx and also fails. Oddly, this is limited to Word files. Similarly named PDFs and PowerPoint files work fine. The temporary files created when I attempt to open the offending attachments are saved with the proper folder. I can find them in the Tools->Saved Files, and the full file names appear. Attempting to open them through Thunderbird results in the same error. However, selecting the Open Containing Folder, and then double-clicking them from there (taking Thunderbird out of the loop) works as it should. I've tried safe mode, but that did not fix the problem. She can forward the email to me, and I can open it on my laptop.....using version 68.3. If I replace the spaces with underscores and ship the file back to her, it opens without incident. The settings on our installations are the same, both using Windows 10, both with Word 2016. I've tried repairing the folder (Inbox), compacting, and even deleting the msf file so it could be rebuilt, but the problem persists. In scanning the database, I found an old problem that is similar: content-disposition filename cut (truncated) at space. That problem was resolved 16 years ago. As best as I can tell, that problem involved saving the file, whereas in this case the temporary files are being saved correctly, but Word is being told to open a file with only the portion of the name until the space, and then additional files between the spaces. I tried reinstalling 68.3, but got the same results. I rolled her back to 68.2.2 and restoring a profile from the day before the upgrade, and everything works as it should. There is nothing peculiar about her configuration. The only thing not by default is her email data (not the profile) is stored in a separate partition on her SSD, a D partition devoted to data storage only. Disabling the internet security did not help. Since the email data was unchanged in the restore process, the problem does not lie in the data file. Any suggestions? Configuration details are available, if needed.

Ausgewählte Lösung

Upgraded the offending system to 68.4.1 and the problem has been resolved.

Diese Antwort im Kontext lesen 👍 2

Alle Antworten (11)

more options

Even when I change the file name to one word and then try to attach it, or try to attach a file whose name was already one word, I get the message that the file name or path was invalid. The message box that shows first gives the last word in the folder name as the file name. When I OK it, I see another message box that was behind it, giving the last word in the name of the folder followed by the correct name of the file. This happens to doc files. I can attach an image or txt or spreadsheet, but if I try to attach a pdf, the pdf viewer says file not found. This wasn't happening a until few days ago.

more options

I have: Win 10 Pro MS Office 2010 TB 68.3.1

Since the upgrade to 68.3.1 I have the problem with .doc and .docx, so the reply that said it is being resolved in 68.3.1 is incorrect. Trying to double click the attachment within the email within TB results in "File doesn't exist". Furthermore, using file explorer to find the attachment down in the bowels of C:Users results in the same problem even although I am cutting TB out of the loop. Double clicking on the (correct) file name also gives the message that the file doesn't exist. Somehow the attachment, although stored in C:Users, appears corrupt; or the file name is registered but there's no file behind it.. I have checked TB file associations and it is correctly identifying WINWORD.EXE as the app to use for .doc and .docx. For me personally this is a major problem.

more options

TB 68.4.1 is available, and although I haven't tested all file types, the one reported in my first reply now opens properly. Check Help/About TB for updates.

more options

68.4.1 fixed me. Thanks to all!

Geändert am von john93

more options

Yes, 68.4.1 works. I can now open attachments .doc and .docx. Thanks to all.

more options

After the update, it seems I can now open all attachment types without issue. Thanks

more options

sfhowes said

TB 68.4.1 is available, and although I haven't tested all file types, the one reported in my first reply now opens properly. Check Help/About TB for updates.

I'm hoping to get a chance to upgrade my wife's system either tomorrow while she is out or this weekend. The fall back from 68.3 was not simple, since I also had to restore a profile from 68.2. Let's just say patience is not her middle name.

Looking at the responses for 68.4.1, I have confidence, though. I'll post a thumbs up or down after I get her upgraded.

more options

Can one go back to a prior version of Thunderbird until this bug is fixed??

more options

Never mind. Upgraded to 68.4.1 and the bug has been fixed. Thank you developers and support team.

more options

Ausgewählte Lösung

Upgraded the offending system to 68.4.1 and the problem has been resolved.

more options

Confirmed, bug fixed in patch level 68.4.1.

  1. 1
  2. 2