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.