Closed
Bug 8076
Opened 25 years ago
Closed 25 years ago
[PP] Mail needs C:\TEMP directory to be created manually - or it doesn't work
Categories
(MailNews Core :: Backend, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M10
People
(Reporter: hyp-x, Assigned: mscott)
References
Details
(Whiteboard: [PR1])
I'm currently using 1999061208 on win98.
It took me a lot of time to realize why mail doesn't work for me at all.
It tries to use a directory named C:\TEMP but doesn't create it.
At first I thought I was missing something, so I read both the release-notes
and the how-to-setup-your-prefs docs, but neighter of them mentions that I have
to create that directory.
Personally I don't think it is a good idea to hardcode the path of the temp
directory; the program should use the TEMP environment variable.
Updated•25 years ago
|
Assignee: phil → mscott
Comment 1•25 years ago
|
||
Reassigning to mscott. Your call as to whether we should read the environment
variable to get the EML file, or whether we should just fix it with whatever
stream API Necko uses.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M8
Assignee | ||
Comment 2•25 years ago
|
||
This is a total hack used to display messages until Necko lands. I really don't
want to waste any time fixing the hack up. The release notes used to say that
you needed a c:\temp directory on windows. Apparently this got removed in a
recent milestone. I'll make sure it gets put back in there.
I'll look at and if it is cheap to create a c:\temp directory then I'll add code
to do so. But as I said, when Necko land that *ALL* goes away and there will be
no hard coded path to c:\temp.
Assignee | ||
Comment 3•25 years ago
|
||
I'm going to be removing this hack completely in M9 as part of my necko
integration work. So the requirement will be gone. There's a bug dependency here
on Bug #1775.
I'm going to mark that dependency.
Summary: Mail needs C:\TEMP directory to be created manually - or it doesn't work → [PP] Mail needs C:\TEMP directory to be created manually - or it doesn't work
Comment 6•25 years ago
|
||
Now that Necko has landed, is this bug fixed? If not, can we move this to M10?
Assignee | ||
Updated•25 years ago
|
Target Milestone: M9 → M10
Assignee | ||
Comment 7•25 years ago
|
||
No this bug isn't fixed yet. rhp and I have been having discussions on how best
to remove this hack. Until libmime doesn't try to load the message 3 times, our
performance would actually be reduced if I removed the temp file hack. He and I
have some things we need to work out before we can get rid of this temp file
without hurting performance.
Sounds like this needs to be fixed by PR1, so I added a note in the Status
Whiteboard
Assignee | ||
Comment 9•25 years ago
|
||
I have another bug out there to remove the temp file hack. But until it is
removed, I'm checking in code today that uses
nsSpecialSystemDirectory::OS_TemporaryDirectory to extract the temp directory.
On windows, this involves making a windows sytem call to GetTempPath.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•25 years ago
|
||
I've checked in fixes for displaying news, pop and imap messages. We now use the
environment variable TEMP to specify where the temp directory is. We no longer
hard code to c:\temp.
Comment 11•25 years ago
|
||
Using 1999100320M10 on win98 a hardcoded Temp directory is no longer needed to
view messages. Mac and linux don't require any location to be hardcoded
in prefs.js file either. Verified
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•