[FIXr]Directory service ignores $TMP and $TEMP

RESOLVED FIXED in mozilla1.2final

Status

()

Core
XPCOM
P1
major
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Gareth Randall, Assigned: bz)

Tracking

Trunk
mozilla1.2final
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

16 years ago
In: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2b) Gecko/20021016

When I download files, it appears that the browser insists on using /tmp to
first create a file, then copies it to the right place. Why did someone assume
that /tmp would be large enough? It's disappointing to return to a large failed
download to be told that the disk space ran out, when really it didn't.

Naturally I tried exporting TMP and TEMP to point to larger locations, but
despite this being an acknowledged standard practise, Mozilla ignores it and
continues to "do its own thing" regardless.

Therefore, can someone either:
1. Use $TMP or $TEMP if set.

2. Just save into the directory specified, because the user probably knows
there's enough space there.

3. At least allow a setting to be specified in prefs.js. At first I thought it
had, but "user_pref("browser.download.dir", "mydirectory");" seems to just be
for the default place in the save dialog.
OK. We have many (duplicate) reports of the fact that we should not be using the
temp dir to start with, so with your permission I'm going to morph this bug to
support $TMP and $TEMP.  For reference, setting $TMPDIR will work with current
Mozilla builds....

(as a note, the correct solution is of course #2 from your list; there's a
working patch for that that needs lots of cleanup...)
Assignee: blaker → dougt
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Download Manager → XPCOM
Ever confirmed: true
QA Contact: petersen → scc
Summary: Stop assuming /tmp will be big enough for downloads. → Directory service ignores $TMP and $TEMP
timeless, care to review?
Assignee: dougt → bzbarsky
Priority: -- → P1
Summary: Directory service ignores $TMP and $TEMP → [FIX]Directory service ignores $TMP and $TEMP
Target Milestone: --- → mozilla1.2final
(Reporter)

Comment 4

16 years ago
My apologies, I think I did once encounter TMPDIR but had forgotten about it.

Nice to see the progress being made here!
Comment on attachment 104275 [details] [diff] [review]
mmm... ancient code....

seeing that the default path always adds the trailing /, will this work if TMP
or TEMP do not include it?
yes, because the nsLocalFile impl handles that for us.
that makes me wonder if /tmp/ should have the slash at the end... does that
serve any purpose?
Not really, except for code readability (to make it clear to the reader that
it's a dir name).  Does it really bother you that much?
well... firstly, it made me wonder about the question above. secondly, it does
look somewhat unusual to me... I always think of tmp as "/tmp" not "/tmp/"...

sure, if you disagree, leave it as is. I don't care much.

Comment 10

16 years ago
Comment on attachment 104275 [details] [diff] [review]
mmm... ancient code....

looks fine. r=me
Attachment #104275 - Flags: review+

Comment 11

16 years ago
Comment on attachment 104275 [details] [diff] [review]
mmm... ancient code....

sr=alecf
Attachment #104275 - Flags: superreview+
Summary: [FIX]Directory service ignores $TMP and $TEMP → [FIXr]Directory service ignores $TMP and $TEMP
Created attachment 104522 [details] [diff] [review]
as timeless pointed out, that should be a static...
Attachment #104275 - Attachment is obsolete: true

Comment 13

16 years ago
Comment on attachment 104522 [details] [diff] [review]
as timeless pointed out, that should be a static...

make sure you don't check in those tabs :)
copying sr=alecf
Attachment #104522 - Flags: superreview+
Attachment #104522 - Flags: review+
Created attachment 104525 [details] [diff] [review]
look ma, no spaces
Attachment #104522 - Attachment is obsolete: true
checked in for 1.3a.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.