190812 - attachments with spaces in name fail to download and display

Status: RESOLVED WORKSFORME

(MailNews Core :: Attachments, defect)

Description

[Philip walden]

User-Agent:       Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.3a) Gecko/20021216
Build Identifier: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.3a) Gecko/20021216

If I receive a mail file attachment with spaces embedded in the file name, the
download manager appears to get stuck, the download process seems to never
complete. The helper app that is supposed to display the file, complains that
more than one input file is being specified. It looks like the download manager
is not escaping spaces properly in a unix command when handing off to the helper
application. Files without embedded space display properly.

In prior versions, the download manager generated temporary mangle file names
that never had embeded spaces. The manager seems to use the file names as is,
causing the problem.

Reproducible: Always

Steps to Reproduce:
1.Receve mail with file attachment with embedded space in name
2.Attempt to open file attachement

Actual Results:  
The download manager pops up and hangs in the downloading state

Expected Results:  
Should have shown the file in the helper app.

Comment 1

[Ninoschka Baca]

What OS was being used to create the attached file?
Do you know what type of file was created?

Trunk build 2003-01-21: I sent a file with spaces in the filename (i.e. "space
test.html") on the Mac, then retrieved the file on Windows and was able to open
the file without a hang. 

Comment 2

[Philip walden]

The message with attachment is coming from a MS Outlook-Exchange system. The PC
user is attaching a powerpoint or msword document file directly from their C
drive. The file attachment is named as is from their drive.

I receive the message on my HP-UX (unix) box via an IMAP connection to my
exchange server.

It definitely looks like an embedded space is causing the problem

Comment 3

[Philip walden]

Any update on this issue? 

It continues to be a big detractor using 1.3 as a mailreader. My 0.9.9 version
was more efficient. I get a lot of messages from PC users that send attachements
with "spaces" in the attachement file name.

Comment 4

[Ninoschka Baca]

Trunk build 2003-02-18: WinXP
I configured Outlook for an account on an Exchange Server (5.5). I also created
a powerpoint presentation and a word document, each having spaces in the
filename. In Outlook I created messages, and attached the documents (via Insert
and also Insert As Attachment option), sent them. Then retrieved the messages
using the latest trunk. Double clicked (or right click and selected Open), chose
the appropriate app and the download manager did not hang. Instead, powerpoint
displayed the presentation and word displayed the document successfully.

Would it be possible for you to attach one of the files to this bug report. You
are also welcome to email it to me at [e-mail].

Comment 5

[Philip walden]

Attachment: MSWord document with embedded spaces in file name

This is a sample of a document that fails to download display on my HP-UX
mozilla mailreader

Comment 6

[Philip walden]

Hi Ninoschka. Please review my original report. This problem only manifests
itself on a UNIX (HP-UX) system.It looks as if you tried to duplicate the
problem on a Windows XP system.

I believe the problem is associated with the hand-off to a helper application.
Wherein the command to start the helper app is not escaping the spaces in the
file name, and thus the spaces are treated as separate command arguments and not
as part of the filename.

As further evidence, whenever I attempt to display the file in the above
attachment, I get the following message displayed on my console:

Only one input filename allowed
Usage: /opt/qvp/qvpview [options] filename

This is an error message from the helper app that is stating it is getting more
than one argument (filename). Thus to me it indicates that the spaces in the
filename are being interpreted as argument delimiters. If there are no spaces in
the filename, the helper app displays the file correctly.

I will also forward my test message to the email address you gave.

Comment 7

[Ninoschka Baca]

Copied from an email on 2/20/2003, from Philip Walden:

"...In an attempt to characterize the problem better for you, I discovered that
the helper app installed on my system is in fact a helper script. It is this 
script that is not escaping the spaces in the file name. After correcting the
script, the display problem goes away.

However, I still do have problems saving the attachment to a file.

Here are some experiments I tried:

   1. I verified that I had no filetypes registered in the "Helper Applications"
preferences for this type (msword) file. I reset the ask before opening file flag.
   2. With the message in the mailreader viewer, I click on the attachment icon.
This opens a small list window with the file attachment listed. I right click on
the file and select the "open".
   3. I get the "Downloading", "open with" or "save" dialog.
   4. I can now open or save the file successfully.
   5. However, if at step 2 I select the "save as" command, I get the following
error:
      "Unable to save attachment. Please check file name and try again later."

Helper App: Quick View Plus for HP-UX 10.20. 

Comment 8

[Ninoschka Baca]

Setting to New per Philip's report. 

Comment 9

[Ninoschka Baca]

Can anyone else with HPUX experience add anymore to this bug?

Comment 10

[Jim Dunn]

Using the mozilla 1.4a (or 1.3) hpux 11.00 build 
-I sent the file "hpux test 190812.doc" to myself
-opened up mail
-clicked on "hpux test 190812.doc" in the attachments
-the "Enter name of file to save to" dialog came up
-I save it to "hpux test 190812.doc"
(if I am messing up some step please let me know)

So I can't reproduce the problem using 1.4a or 1.3
(I currently don't have a 12/16/02 build to test)

Comment 11

[Ludovic Hirlimann [:Usul]]

Based on the last comment resolving this as WFM.

Philip Jim if you are still reading those email addresses and still have the issue please reopen.