Closed Bug 370951 Opened 17 years ago Closed 15 years ago

File attachment with a '#' (hash, pound sign) in the name cannot be opened nor saved from imap folder

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Thunderbird 3.0b2

People

(Reporter: tranle, Assigned: Bienvenu)

References

Details

(Keywords: regression, Whiteboard: has patch for review)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a3pre) Gecko/20070219 Minefield/3.0a3pre
Build Identifier: version 3 alpha 1 (20070219)

You cannot save nor open an attachment of a file if its a name contain the character '#' in it.

Reproducible: Always

Steps to Reproduce:
1. Send yourself an email with an attachment of a file named: "a # b.txt" or "a # b.doc"
2. When you receive the email, try to save the attachment to disk.
3. or try to open the attachment for viewing.
Actual Results:  
When you try to save the attachment it create a zero length file.
When you try to open the attachment, nothing happen.

Expected Results:  
Save should write the attachment to disk.
Open should let you view the attachment content in notepad or word.

I am using MS Windows2003 as my desktop environment.
The mail server is an MS Exchange server.
The mail connection is IMAP.
This sounds a lot like bug 243504, but not exactly like it. Which version of Thunderbird are you using?
(In reply to comment #1)

I am using the latest-trunk build of Thunderbird version 3 alpha 1 (20070219)
Well, after further testing, if I save the email to a .eml file, then open the email, then try to open the attachment, I am getting this error in the Error Console:

====
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMessenger.openAttachment]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/msgHdrViewOverlay.js :: openAttachment :: line 1056"  data: no]
====
latest trunk (2008040204) is having issue with opening such file or saving it to disk(empty file saved). But you can save message as EML file and open it afterwards and it works as suppose to be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Assignee: mscott → nobody
Keywords: regression
this appears to be a regression in imap only (well, at least does not fail from local)
xref bug 115091 comment 27 (which obviously is not a 3.x trunk regression)

tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081127 Shredder/3.0b1pre
Summary: File attachment with a '#' in the name cannot be opened nor saved. → File attachment with a '#' in the name cannot be opened nor saved from imap folder
Confirm this bug also reproduces on Windows XP, accessing Dovecot IMAP running on Linux and FreeBSD servers.  I discovered this one independently on the 3.0b1 release and mistakenly filed a dupe, Bug 468890.
Flags: blocking-thunderbird3?
get this on the b2 radar
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b2
OS: Windows Server 2003 → All
Hardware: PC → All
narrowed to regression range of 20061127(works)-20061201(fails).
Bug 472236 has a testcase
narrowed to 1 day range - 20061127(works)-20061128(fails)
bug 358657?

And perhaps there are two bugs / two regressions, because current trunk doesn't even save a 0 byte file.  From bug 472236 comment 9 "some time between 2008060303 and now, it doesn't even save a 0 byte file"


bug 471648 mentions the mailWindowOverlay.js :: UpdateJunkButton console message at approximately the same line#
I'll have to deal with this at some point
Assignee: nobody → bienvenu
Summary: File attachment with a '#' in the name cannot be opened nor saved from imap folder → File attachment with a '#' (hash, pound sign) in the name cannot be opened nor saved from imap folder
BTW, I have found an interesting work-around:  If you do a "file/save as/File", then just double-click on the .eml  from say the desktop, all attachments with "#" are open/saveable normally.  Odd.
Whiteboard: will investigate
Status: NEW → ASSIGNED
Attached patch proposed fix (obsolete) — Splinter Review
This fixes open and save of imap attachments with a '#' in the name. In the OpenAttachment piece of the patch, the fix was to make sure the part number really is just the part number, not everything after the part, because one of the things after the part was an incorrectly escaped filename. For the save attachment piece, we were finding the '#' in the filename instead of the '#' that separates the imap folder from the the message UID, so I had to do an RFind from the middle of the URI.

Asking Neil for r/sr because of his string wizardry.
Attachment #359374 - Flags: superreview?(neil)
Attachment #359374 - Flags: review?(neil)
Whiteboard: will investigate → has patch for review
(In reply to comment #18)
> Asking Neil for r/sr because of his string wizardry.

Such as this possibility, perhaps?

uri += Substring(partStart, nsDependentCString(partStart).FindChar('&'));

This works because a length of -1 means to use strlen. Or you may prefer:

nsDependentCString part(partStart);
uri += StringHead(part, part.FindChar('&'));
Showoff! :-) I'll try the first one.
Attached patch fix addressing Neil's comments (obsolete) — Splinter Review
I went with the second flavor because the first didn't compile (it would have required an nsDependentCString wrapper around the first param as well).

I also tweaked the code to return an error if there was no "part" part in the url.
Attachment #359374 - Attachment is obsolete: true
Attachment #359771 - Flags: superreview?(neil)
Attachment #359771 - Flags: review?(neil)
Attachment #359374 - Flags: superreview?(neil)
Attachment #359374 - Flags: review?(neil)
(In reply to comment #21)
> I went with the second flavor because the first didn't compile (it would have
> required an nsDependentCString wrapper around the first param as well).
Actually that's wrong too. Stupid internal/external string API differences :-(
Attachment #359771 - Attachment is obsolete: true
Attachment #359805 - Flags: superreview?(neil)
Attachment #359805 - Flags: review?(neil)
Attachment #359771 - Flags: superreview?(neil)
Attachment #359771 - Flags: review?(neil)
What I meant was that the first version only worked with the external string API; it would have required a rewrite to work with both APIs.
Attachment #359805 - Flags: superreview?(neil)
Attachment #359805 - Flags: superreview+
Attachment #359805 - Flags: review?(neil)
Attachment #359805 - Flags: review+
Comment on attachment 359805 [details] [diff] [review]
mix the two approaches

>+    uri += Substring(part, 0, part.FindChar('&'));
StringHead is just an inline wrapper around Substring anyway, so no great loss if you don't want to use it.

>+  // in that part of the uri, if the attachment name contains '#', 
Nit: trailing space. Ironic, as you removed 7 other whitespace errors :-)
fix with nit addressed, thx!
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
v.fixed using current trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.