Nightly builds not cleaning up older GRE directory

RESOLVED WONTFIX

Status

Core Graveyard
Installer: GRE
RESOLVED WONTFIX
14 years ago
6 years ago

People

(Reporter: Derwood, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040107
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040107

Each nightly installs it's GRE files in [program files path]\common
files\mozilla.org\GRE\[build_version]

When a new nightly is installed overwriting an earlier build, the older GRE
fiels are not removed.  The [program files path] starts to bloat to the tune of
~15M each time a build is installed.

Reproducible: Always

Steps to Reproduce:
1. Install a nightly build check GRE common files path
2. Install a later nightly.
3. Note how older versions are not removed despite main files overwritten.

Actual Results:  
Bloat

Expected Results:  
Clean up older files.
(Reporter)

Comment 1

14 years ago
dup of bug 198081, but I can't reopen that one.

Comment 2

14 years ago
per reporter's comment

*** This bug has been marked as a duplicate of 198081 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Regression of bug 198081. I don't believe it's the same bug--the code added to
fix that bug is still there, it's just not getting tickled. In some cases the
contents are deleted but the empty directory remains.

Tracking the regression separately (likely a build/config issue) is less
confusing than lumping it into the original feature bug.
Status: RESOLVED → UNCONFIRMED
Keywords: regression
Resolution: DUPLICATE → ---
I'm still not seeing this. I do see that an *empty* directory gets left behind
(a minor bug), but several of the dupes have specifically mentioned eating up
Megabytes of diskspace (more important bug).

Many, but not all, of the dupes since bug 198081 were fixed have been on Win9x.
I have not tested there, but some reports, like this one, do mention WinXP

I'll confirm for the empty directory problem. How can I reproduce the other
issue? Any ideas, Sean?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Nightly builds not cleaning up older GRE files → Nightly builds not cleaning up older GRE directory

Comment 5

14 years ago
It might be a registry problem, but it's hard to say.

Darin, can you attach an export of your windows registry from the following key
on down:
  HKLM\Software\Mozilla

Please make sure to save the export file as type "Win9x/NT4 Registration Files"
for readability purposes.
(Reporter)

Comment 6

14 years ago
Created attachment 161514 [details]
winXP registry export

Comment 7

14 years ago
Sorry, my bad.  I meant:
  HKLM\Software\mozilla.org

(not Mozilla).
(Reporter)

Comment 8

14 years ago
Created attachment 161515 [details]
ssu's a ****

I hear and obey

Comment 9

14 years ago
from speaking with lohphat, it doesn't seem to be an issue for him anymore.  He
does have 1 empty GRE dir, and that's it.

He's going to install tomorrow's build and verify the non-issueness.
(Reporter)

Comment 10

14 years ago
Created attachment 161575 [details]
older moz versions in registry

These should have been cleaned when a newer version is installed.
(Reporter)

Comment 11

14 years ago
Today's build cleaned the GRE directory, no empty folder.

Should I open another bug on the registry cleaning issue? (see attachment)

Comment 12

14 years ago
yes, please open a new bug on the registry problem.

btw, dveditz and I tracked down the related empty GRE dir being left around
after an upgrade problem.  It only happens if you "launch" the new nightly
mozilla installer from the browser's download manager dialog to upgrade it (with
options left at default).

The problem did not occur if the new nightly mozilla installer was launched from
outside the browser's download manager (ie, via the explorer).

This happens because of a couple of combined things:
 1) mozilla.exe's cwd after start up is the GRE dir because that's where
xpcom.dll (and support) files are at.  This is necessary due to the way Windows
automatically locates dependent dlls.
 2) the "launch" command in mozilla's download manager calls ShellExecute
without specifying a working dir, thus it defaults the executing app's working
dir to be the same as mozilla's working dir.

The last item (2) prevents the GRE dir from being removed on upgrade.

Comment 13

14 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910

Still a problem regarding GRE in Windows registry while installing 1.7.3 over
1.7.2 (not nightly builds but end-user releases).  

Note that this problem was seen without use of Mozilla's Download Manager (see
comment 12).  Instead, I downloaded the executable installer using a non-Mozilla
FTP client.  After the download completed, I shutdown my Internet connection and
all applications (having previously shutdown Mozilla), cleaned up, launched an
installation logger, and then executed the installer.  
(Reporter)

Comment 14

14 years ago
Bug 264386 created for other registry cleanup problem.
Product: Core → Core Graveyard
The GRE installer is long dead
Status: NEW → RESOLVED
Last Resolved: 14 years ago6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.