48225 - Install.log: Crash results when writing to read-only file

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect, P1)

Description

[Jimmy Lee]

Build: 2000-08-08-09-M18(WIN), 2000-08-08-11-M18(MAC), 2000-08-08-08-M18(LINUX)

1. From the Netscape directory, mark the install.log as read-only.  If no such 
   file exists, then make one.
2. Launch Seamonkey
3. From http://jimbob/trigger3.html, trigger any test case
4. Click Install button from the confirmation button

RESULT:
Crash.  Installation does occur.

EXPECTED RESULT:
No crash.

TalkBack Incident ID: 15513534

Stack Trace
nsLoggingProgressListener::AfterJavascriptEvaluation 
[d:\builds\seamonkey\mozilla\xpinstall\src\nsLoggingProgressNotifier.cpp, line 
145] 
nsTopProgressListener::AfterJavascriptEvaluation 
[d:\builds\seamonkey\mozilla\xpinstall\src\nsTopProgressNotifier.cpp, line 117] 
RunInstallOnThread 
[d:\builds\seamonkey\mozilla\xpinstall\src\nsSoftwareUpdateRun.cpp, line 492] 
_PR_NativeRunThread [pruthr.c, line 421] 
MSVCRT.dll + 0x3820 (0x78003820) 
KERNEL32.dll + 0x4ee8 (0x77f04ee8)

Comment 1

[Jimmy Lee]

Adding keyword, crash.

Comment 2

[Daniel Veditz [:dveditz]]

Urgle, good catch!

Comment 3

[Daniel Veditz [:dveditz]]

OK guys, any thoughts about how we should handle this one? A read-only bin 
directory is actually going to be pretty common on Linux and some WinNT 
systems. What choices do we have?

- keep install.log where it is, but if it's unwritable write to the profile 
directory instead.
- keep install.log where it is, when unwritable don't write anything (i.e. 
prevent the crash only)
- always write install.log into the current profile directory (what about the 
embedded case when there is no profile?), unless told at startup to use a 
different place as in the wizards

Also, I'm swamped -- any volunteers to take this bug?

Comment 4

[Daniel Veditz [:dveditz]]

Setting p1 for critical nsbeta3+ bugs

Comment 5

[Samir Gehani]

Mine I guess.

Comment 6

[Samir Gehani]

Dan's first suggestion is the decided behavior for this fix (info for 
verification). 

When installing a .xpi from the browser:
1> If we can write to the dir where mozilla exists, install.log is created 
   there.
2> Else we write to the user's mozilla profile directory which is   
   platform-specific:
     Unix:   ~/.mozilla
     Win32:  ..\Users50\<username>
     Mac:    <bootvol>:Documents:Users50:<username>

Rationale:
In the case of Unix, if the install was done by root, when root installs 
software it is probably global so the install.log in the mozilla directory will 
be updated.  All users will probably be able to read this.  When a non-root user 
installs, the software will probably not be global and so the user-specific 
install.log should be updated.  

In the case of Mac, this is never an issue.  Most likely the user will always 
have write-access to the mozilla directory and the install.log next to the 
mozilla binary will always be updated.  

In the case of Windows, if we are on a WinNT-type system (which behaves 
Unix-ish) then the Unix behavior will be appropriate, i.e., install.log for 
user-installed packages will be in user-specific mozilla profile directories 
(where they will have write-access).  In the case of a Win9x-type system (which 
behaves Mac-ish) the install.log will be created in the mozilla directory since 
we will detect write access to that directory.  Of course, in the event that 
users on a WinNT-type system have access to the directory where the mozilla 
binary exists, the install.log will be created/updated there.

Comment 7

[Phil Peterson]

PDT agrees P1

Comment 8

[Samir Gehani]

Fix in hand awaiting review.

Comment 9

[Samir Gehani]

Fix checked in.

Comment 10

[Jimmy Lee]

Build: 2000-09-07-09-M18(WIN), 2000-09-07-04-M18(MAC), 2000-09-07-08-M18(LINUX)

No more crashing.  We write to the install.log if we can.  If the file and/or 
directory is locked, we write to an install.log in the profile directory.

Marking Verified!