Closed Bug 126275 Opened 23 years ago Closed 23 years ago

%HOME%TMP not resolved

Categories

(MailNews Core :: Composition, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: guivho, Assigned: bugzilla)

Details

On my win2k box with build 2002021803 I get following error when sending mail:

Send Message Error

Sending of message failed.

Unable to open the temporary file C:\PROGRAM
FILES\MOZILLA.ORG\MOZILLA\%HOME%TMP\nsmail.eml. Check your 'Temporary Directory'
setting.

1) Message formatting sucks: Upcase directories usually are
printed with one single capital; 'Program Files' should not be split over two lines

2) Problem caused by the way my environment is setup under windows:

set HOME=C:/
set TMP=%HOME%tmp

This resolves to TMP being 'c:/tmp' which works fine for all cygwin tools, 
gvim, emacs etc... It used to work with previous builds of Mozilla. It does no 
longer work with this build.

Note that it is common practice to define environment variables using previously
defined variables. I think mozilla should not trip over this. I have been
happily sending mail with earlier builds while my TMP was defined in that way.
I had to switch to 'set TMP=c:/tmp' to be able to send mail with this build.
This problem does not occur anymore. Now %HOME%tmp is always properly expanded
into c:/tmp, even when it is defined as %HOME%tmp.

This was probably a temporary win2k problem, and not a mozilla problem.

I went back and redefined TMP as %HOME%tmp, rebooted, verified that this was the
current setting. And still Mozilla works as a breeze...

Problem fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
No one reads TMP directly AFAIK, we all use the "directory service", which
ultimately calls the Windows api GetTempPath() for this.

http://lxr.mozilla.org/seamonkey/search?string=OS_TEMP

So I'd say that argues for some weirdness in your OS installation, which seems
to be your conclusion as well.

By the way, FIXED usually means we've done something on our end to make the
problem go away.  In this case WORKSFORME might have been a better resolution,
or perhaps the unfriendly INVALID (not a Mozilla problem). Don't worry about
changing this bug's resolution, but keep in mind for the future (when in doubt
the label links at the top of this page lead to documentation of the terms we use)
changing resolution to invalid
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
invalid
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → INVALID
Verified invalid.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.