Closed Bug 55591 Opened 20 years ago Closed 19 years ago

Unable to send mail msg with attachment specified via UNC name

Categories

(MailNews Core :: Composition, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.6

People

(Reporter: law, Assigned: bugzilla)

References

Details

(Whiteboard: Have fix)

Attachments

(1 file)

I composed a message and attached a file.  I specified the file (via the file
picker) using UNC name (e.g., "\\law\d\dropbox\initial.jpg"). When I try to send
the message nothing happens (the compose window remains). On the console I see
this message:

SendMessage from XUL
GenericSendMessage from XUL
Identity = [nsIMsgIdentity: id2]
attachments = file:////law/d/dropbox/initial.jpg

RECEIVE SaveAndSendProcessDone

failed to SendMsg
QA Contact: esther → pmock
reassign to rhp
Assignee: ducarroz → rhp
Adding CC
reassigning to ducarroz
Assignee: rhp → ducarroz
Assign it to myself
QA Contact: pmock → fenella
To Esther..
QA Contact: fenella → esther
This bug is not Windows 98 specific, it shows up on (at least) Windows NT 4.0
and Windows ME as well.
It now gives a dialog box, "Unable to send message." You get the same message if
you try to save it in the Drafts folder. This is on Windows 2000.
I think this probably needs to be blocked by a networking:file bug. we don't 
really handle unc addresses. cc netwerk folks.
This bug is probably related to bug 8684.

This bug probably depends on bug 66194.
According to "Doug T"'s comment from 2001-06-12 08:49 to bug 66194 (which I
still think should block this bug btw, why isn't it?), UNC:s can now be written
as "file://///server/path".  That notation doesn't work for me using Mozilla
0.9.1 on Windows NT 4.0, but the change may very well have gone in later than that.
*** Bug 81688 has been marked as a duplicate of this bug. ***
Depends on: 66194
As of 0.9.2, I can access files from the "Network Neighborhood" using the
file://///server/path syntax.
*** Bug 80682 has been marked as a duplicate of this bug. ***
*** Bug 89038 has been marked as a duplicate of this bug. ***
*** Bug 88382 has been marked as a duplicate of this bug. ***
*** Bug 95414 has been marked as a duplicate of this bug. ***
*** Bug 95758 has been marked as a duplicate of this bug. ***
Though it does not fix the bug, 95% of my problems as a sysadmin would be solved
if only Mozilla displayed a short message regarding UNC paths instead of "Send
Failed". Would it be possible to include something like that in the next milestone?
*** Bug 96522 has been marked as a duplicate of this bug. ***
*** Bug 98538 has been marked as a duplicate of this bug. ***
*** Bug 100658 has been marked as a duplicate of this bug. ***
Depends on: 101953
Accepting and working on it...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
The problem comes from the fact the code that theat local file attachment use
the old API nsFileSpec and this one does not work very well with UNC file name.
The code for remote attachment does not have this problem. Anyway, we should
threat UNC files as remote attachment because we need to read them
asynchronously in case the network is slow, that will allow the user to be able
to cancel the fetch.
Attached patch proposed fix, v1Splinter Review
Whiteboard: Have fix
*** Bug 103398 has been marked as a duplicate of this bug. ***
*** Bug 103510 has been marked as a duplicate of this bug. ***
Comment on attachment 52306 [details] [diff] [review]
proposed fix, v1

r=varada
UNC will be treated as a remote attachment and I guess that is ok.
Attachment #52306 - Flags: review+
Comment on attachment 52306 [details] [diff] [review]
proposed fix, v1

sr=mscott
Attachment #52306 - Flags: superreview+
Fixed and checked in
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 108042 has been marked as a duplicate of this bug. ***
*** Bug 112072 has been marked as a duplicate of this bug. ***
Verified -  I had trouble reproducing this bug after installing several builds,
I found this works without having to map to the drive using trunk builds 10/15,
11/21, 11/29, and 12/3.  This was fixed on 10/9 trunk build only, because the
10/22 branch build did not work (I encountered the same Send Fail as reported).
 If anyone in this bug or on duplicates can reproduce this on trunk builds after
11/29/2001 please update this bug and give your specific steps.  
Status: RESOLVED → VERIFIED
Blocks: 101953
No longer depends on: 101953
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.