# Enhancement: Add a flag to provide an alternate 'Application Data' directory

NEW
Unassigned

## Status

### ()

Toolkit
Startup and Profile System
P3
enhancement
NEW
13 years ago
7 months ago

Trunk
---
x86
Windows XP
Points:
---

## Attachments

### (1 attachment)

 2.84 KB, patch Details | Diff | Splinter Review
(Reporter)

### Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0 (Firefox-Comm-Ed-mmoy-1.0-P3W-X9)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0 (Firefox-Comm-Ed-mmoy-1.0-P3W-X9)

Request For Enhancement: Under Windows XP, Firefox stores files (profiles.ini &
pluginreg.dat) in the Users 'Application Data' directory, usually 'C:\Documents
and Settings\<user>\Application Data\Mozilla\Firefox'. This causes problem for
users who wish to customize this, usually for portability (USB key or WinPE (or
BartPE)).

I propose that an environment variable check be added to provide a custom value
for this directory (similar to MOZ_PLUGIN_PATH for the Plugin directory). The
variable would probably be called MOZ_APPDATA_PATH and would be set by the user
before starting Firefox.

I do NOT have build resources here, but I MAY be able to provide a patch for
this soon.

Reproducible: Didn't try

Steps to Reproduce:
At a command prompt:
SET MOZ_APPDATA_PATH=<custom>
start firefox.exe
Actual Results:
Firefox started and used the profiles.ini, etc at
C:\Documents and Settings\<user>\Application Data\Mozilla\Firefox

Expected Results:
Firefox started and used the profiles.ini, etc at <custom>
(Reporter)

### Updated

13 years ago
Blocks: 272983
Component: General → Startup and Profile System

### Comment 1

13 years ago
have you tried using the -profile command line flag to firefox?

"firefox -profile e:\foo\bar"

be sure to create the directory "e:\foo\bar" before running firefox in this way.
note: the only problem i've found with this approach is that it does not invoke
the profile migration code, and moreover it also does not seem to copy over
default bookmarks and other such files.  but, otherwise it works great for me.
(Reporter)

### Comment 2

13 years ago
Created attachment 175630 [details] [diff] [review]
Proposed patch, v1

Here's a proposed patch. Beware, I have NO build tools on this machine, so this
was created by hand.
(Reporter)

### Comment 3

13 years ago
(In reply to comment #1)
> have you tried using the -profile command line flag to firefox?
>
>   "firefox -profile e:\foo\bar"
>
> be sure to create the directory "e:\foo\bar" before running firefox in this way.
>  note: the only problem i've found with this approach is that it does not invoke
> the profile migration code, and moreover it also does not seem to copy over
> default bookmarks and other such files.  but, otherwise it works great for me.

Even when specifying a profile, the AppData folder gets created and at least
partially used (for pluginreg.dat, at the very least). If this can be
user-specified by environment variable, it can be used, for example, on a BartPE
CD, with Firefox on the CD, but AppData (and profiles) on a RAMDisk.

ZC

### Comment 4

13 years ago
I'm confirming this, even though I'm not sure what the difference is between
this and -profile, except that bug 272983 would have to be fixed to make the
profile entirely located in the specified directory.
Status: UNCONFIRMED → NEW
Ever confirmed: true

### Updated

13 years ago
Assignee: firefox → nobody
QA Contact: general → startup
Version: unspecified → Trunk

### Comment 5

13 years ago
I am very unlikely to support an environment variable for this, but a
command-line flag or a file sitting next to the firefox executable might be a
useful feature for USB sticks and standalone CDs.
Assignee: nobody → benjamin
Summary: Enhancement: Add an environemt variable to provide an alternate 'Application Data' directory → Enhancement: Add a flag to provide an alternate 'Application Data' directory

### Updated

13 years ago
Priority: -- → P3
Target Milestone: --- → Firefox1.1

### Comment 6

13 years ago
Unfortunately, it looks like Firefox also hard codes the application directory.
Specifically, it appears to use %USERPROFILE%\Application Data instead of using
the %APPDATA% environment variable.  So, even if you wrap Firefox in a launcher
that passes in a different APPDATA value, Firefox will ignore it.

I noticed this while working on Portable Firefox and was sure it had already
been filed as a bug.  If you'd like to test this without messing with your own
environment variables, try using this launcher:
http://forums.mozillazine.org/viewtopic.php?p=1777005#1777005

### Comment 7

13 years ago
>  Specifically, it appears to use %USERPROFILE%\Application Data instead of using
> the %APPDATA% environment variable.  So, even if you wrap Firefox in a launcher
> that passes in a different APPDATA value, Firefox will ignore it.

We use the correct Windows system call to find the Appdata directory:
http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsXREDirProvider.cpp#740

### Comment 8

13 years ago
I believe that the appdata value is stored in a registry key.

### Comment 9

13 years ago
(In reply to comment #8)
> I believe that the appdata value is stored in a registry key.

That may explain it.  If Firefox has ever been run on a machine, it will ignore
a change in the %APPDATA% variable.  Either way, the end result is that it will
only respond to a different %USERPROFILE% environment variable in my tests with
Portable Firefox, which will allow the pluginregistry to be on the key, but
breaks the Desktop and My Documents sections within file dialogs.

### Comment 10

13 years ago
(In reply to comment #9)
> That may explain it.  If Firefox has ever been run on a machine, it will ignore
> a change in the %APPDATA% variable.  Either way, the end result is that it will
> only respond to a different %USERPROFILE% environment variable in my tests with
> Portable Firefox, which will allow the pluginregistry to be on the key, but
> breaks the Desktop and My Documents sections within file dialogs.

Actually, that doesn't explain it.  If you try out the launcher I linked to and
set a different userprofile environment variable (but leave appdata completely
untouched), Firefox will actually create an Application Data directory within
the USERPROFILE directory and drop the pluginregistry there.  This doesn't seem
to be a behavior of Windows as reversing the variables (APPDATA set, USERPROFILE
standard) causes the pluginregistry to be placed in Documents and Settings.
Perhaps it is hard coded within the pluginregistry section.

### Comment 11

13 years ago
%USERPROFILE% affects it, but %APPDATA% does not, because it is stored in the
registry as a REG_EXPAND_SZ (variable replacement string) as:

AppData: %USERPROFILE%\Application Data

This means that the application data folder applications get - along with the
other profile folders - do depend on %USERPROFILE% (the Win32 API call will just
extract the right value from the registry, at least for these profile folders).
%APPDATA% is, I think, set by Explorer when logging in, and is only a
convenience for scripts and such.

This of course doesn't really help if you want to control explicitly where Moz
or FF want to put their data, but should explain the behaviour you're seeing.

### Comment 12

13 years ago
(In reply to comment #11)
> %APPDATA% is, I think, set by Explorer when logging in, and is only a
> convenience for scripts and such.
>
> This of course doesn't really help if you want to control explicitly where Moz
> or FF want to put their data, but should explain the behaviour you're seeing.

Ah, thanks James.  That makes sense.  But, yes, it is unfortunate.  I was hoping
the %APPDATA% environment variable would be the perfect workaround to this issue.

### Updated

12 years ago
Target Milestone: Firefox1.5 → ---

### Updated

10 years ago
Assignee: benjamin → nobody
(Assignee)

### Updated

10 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.