52016 - moz deposits app data in %windir%

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: BackEnd, enhancement, P3)

Description

[jon rekai]

win95 build (last working for me, 2000082915)

. creates %windir%\desktop\registry.dat on startup and
. deposits mozregistry.dat in %windir%.  also
. creates %windir%\mozilla\ when permitted.

winnt not so bad, %windir%\mozregistry.dat is only offender observed.

bad, bad, bad!  keep app files in appdir!

Comment 1

[David Krause]

Jon, please see bug 6464 and
news://news.mozilla.org:119/39AC0F4E.EB2DF5FA%40netscape.com

I think maybe some environment variables are pointing to weird places on your
win95 box. The %windir%\mozilla is your profile and is supposed to be in
Application Data I believe.  The %windir%/desktop/registry.dat is supposed to be
there also.  So maybe either your box doesn't have something set right or the
info in that bug is wrong about win95.

I do concur with you about c:\winnt\mozregistry.dat on windows nt.  It probably
needs to live in a different place.  It isn't in the appdir because the appdir
may not be writeable.  But of course c:\winnt might now be writeable either. :)

Comment 2

[jon rekai]

hmm- maybe env vars that dont exist?  there is an 'application data' dir on 
later w9x releases, which i believe may also be created by installing certain 
microsof*t apps, but i don't think it'll be found on a clean w95 install.  i 
see what the objective is according to 6464, but there should be some 
non-disruptive fallback for systems operating in a single user environment, 
such as maintaining at least a default profile in the moz app dir.  this w95 
installation is completely ignorant of users and profiles, and security is 
implemented at the hardware level.

the winnt install does have the 'normal' user profile dirs.

about the %windir%/desktop dir, i'd guess that's a fallback measure.  why would 
anyone want a 'folder' with mozregistry.day in it on their desktop?  maybe a 
link to the moz binary, but not a data file useless to the user.

i'll attempt to locate the proper name of and add a test application data env 
var and see what happens.  maybe i'll d/l the html source, too, and browse a 
little (j/k on the html format;)

Comment 3

[racham]

The fallback, if there is no application data folder, is Windows directory. The
name of the new registry on windows is registry.dat.

Comment 4

[jon rekai]

the 'shell folder' CSIDL_APPDATA is an IE4 thing according to microsof*t's 
docs, so it definitely won't be found on the windows installations on this 
machine.  GetWindowsDirectory is the fallback.  i doubt adding the registry key 
for application data will have any impact, as the shell support isn't there 
(err.. here).  it looks like GetDefaultUserProfileRoot in 
nsAppFileLocationProvider.cpp#498 is responsible for the tree in %windir%, but 
why fall back there instead of the app's dir?

Comment 5

[racham]

app's dir you mean the place where app is installed ? We moved the Users folder
from there (2 levels above exe) to the new location (bug 6464). Later found out
some of these machines may not return any good value for CSIDL_APPDATA. So,
added a fallback to be Windows which certainly exists on all machines. Making
install dir or anywhere near to be user folder location would be like undoing
bug 6464's fix.

Adding Conrad to the cc list.

Comment 6

[jon rekai]

i don't think falling back to mos's bin for user/profile data would undo 6464.
if it's determined the os supports multiple user profiles, it'd be silly not to
take advantage of the os support. otherwise, the logical place to fall back to
would be the app's root, moz's bin, not one of the os's dirs.  moz would then be
non-intrusive in either case.

Comment 7

[Asa Dotzler [:asa]]

updating component and owner

Comment 8

[racham]

Reassigning to myself.

Comment 9

[jon rekai]

spoils a good app....

 Directory of C:\windows

.              <DIR>        08-11-99  7:58p .
..             <DIR>        08-11-99  7:58p ..
command        <DIR>        08-11-99  7:58p command
config         <DIR>        08-11-99  8:00p config
cursors        <DIR>        08-11-99  8:00p cursors
desktop        <DIR>        09-01-00  6:25p desktop
fonts          <DIR>        08-11-99  7:59p fonts
help           <DIR>        08-11-99  7:58p help
inf            <DIR>        08-11-99  7:58p inf
mozilla        <DIR>        10-02-00  9:08p Mozilla
msdun          <DIR>        08-11-99 11:51p msdun
mstcpip        <DIR>        06-21-00  7:55p mstcpip
sendto         <DIR>        08-11-99  8:03p sendto
spool          <DIR>        08-11-99  8:03p spool
startm~1       <DIR>        08-11-99  8:03p start menu
sysbckup       <DIR>        08-11-99  8:03p sysbckup
system         <DIR>        08-11-99  7:58p system
ws2bakup       <DIR>        08-12-99  7:16a ws2bakup

Comment 10

[jon rekai]

*** Bug 52017 has been marked as a duplicate of this bug. ***

Comment 11

[racham]

Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.

Comment 12

[Henrik Gemal]

I'm trying to find bugs related to the creation of the:
- mozregistry.dat
- mozver.dat
- nsreg.dat
files.

Deleting them has no influence on Mozilla so I think there are obsolete. Am I wrong?

Comment 13

[Benjamin Smedberg]

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.