71113 - Log files should not prevent installation

Status: VERIFIED FIXED

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

Description

[Jaime Rodriguez, Jr.]

Release: 6.01
Reproducible: Always

The user should not experience an istallation failure when custom.log, full.log, 
or typical.log files are not in the xpi directory.

During the 6.01 release, AOLT Ireland removed these log files because they 
thought they were extraneous files created by the PUSH process. Not having these 
files in the XPI directory caused the 6.01 JA to fail in our outside the 
firewall testing.

Should we have a hard line dependency on these files?

Comment 1

[selmer (gone)]

Hmmm.  I thought you said the failure to download the files was the root evil,
not that they decided to put an incomplete package on their download site.  I
think they need to put these checkpoint files on their site ASAP.

However, we should not allow the install to fail if one of these files fails to
download for some reason.  (The incidence is supposed to be low, but ftp server
problems could invalidate that argument.)

Comment 2

[Jaime Rodriguez, Jr.]

Agreed, the log files were replaced in the directories prior to our release of 
6.01a JA.

Further, I agree with the comment, "we should not allow the install to fail if 
one of these files fails to download for some reason". It seemed like a huge 
dependency to me at the time - - probably because it caused us such grief.

Comment 3

[Daniel Veditz [:dveditz]]

There's really nothing we can do for 6.01 since we were asked to create a 
config.ini-only solution (lower risk than a code change). Either QA the site 
before you push, or take the files out of the config.ini.  We won't be doing 
this on the trunk because we're not getting usable numbers out of it.

Netscape-only bugs in bugzilla are bad news -- we have been repeatedly asked to 
stop doing that. Please use bugSCAPE or write so that it's public.

Comment 4

[Jaime Rodriguez, Jr.]

Yeah, this is closed for 6.01. We FIXED the problem on the server, by placing 
the files back in the XPI directories where they belonged before we released 
publicly. Doing outside the firewall testing was a life-saver in this case.

Steve asked me to log the bug, after I brought it up in 6.5 leads meeting. I was 
just making sure that we were doing things a bit differently for 6.5 Install 
(seems like we are).

I guess the current concern would be what he explained, "we should not allow the 
install to fail if one of these files fails to download for some reason.  (The 
incidence is supposed to be low, but ftp server problems could invalidate that 
argument.)"

Comment 5

[Daniel Veditz [:dveditz]]

That's just not possible for 6.01 -- either we download the files, or we don't. 
If any one of the downloaded components fails then the install fails.

Comment 6

[Jaime Rodriguez, Jr.]

Agreed, as stated in the previous message, 'We FIXED the problem on the server 
. . .' for the 6.01 release. 6.01 is closed, and from you said, we won't be 
using the same type of mechanism in the 6.5 release.

Comment 7

[Gregg Landskov (gone)]

Just to add my 2 cents.  I think these marker files are GREAT.  Even though our 
ftp reporting is broken right now, the numbers we are getting for "marker".log 
tell us a lot.  

I would push strongly that these .log files are included for all clients that 
use xpi files for downloading.

Comment 8

[selmer (gone)]

Dan, this isn't about anything 6.01.  Did your statement mean that we haven't
implemented the marker files in the trunk?  I thought we agreed at the installer
meeting last week that the marker files were important on the trunk.  Assuming
that we're going to use them, then this bug is to make sure failures with those
files don't fail the install.

Comment 9

[Daniel Veditz [:dveditz]]

we need a new flag that says to ignore download failures. Heh, this is almost 
the exact inverse of the "REQUIRED/CRUCIAL" flag we've talked about (and 
decided not to do). For now let's restrict its use to DOWNLOAD_ONLY files 
because I don't want to figure out the UI implications of archives that didn't 
download, but keep in mind that if we find we're getting a lot of download 
failures on big otpional things like Java or Real we may want to extend this to 
other download types.

Comment 10

[Sean Su]

feature added.  There are two new attributes for a component:
  IGNORE_DOWNLOAD_ERROR
  IGNORE_XPINSTALL_ERROR

When the log file are placed back into the 6.5 installers, the above attributes 
can be used.

Comment 11

[Jimmy Lee]

Build: 2001-04-05-10-trunk(WIN)

Looks good.

I set IGNORE_DOWNLOAD_ERROR attribute from the config.ini, and during download 
the missing xpi did not stop all downloads.  There was an expected error at the 
time of copying files.

IGNORE_XPINSTALL_ERROR was set in a second test.  If the specified xpi for 
download is absent, then we get an error dialog that we cannot install (no 
error during download with IGNORE_DOWNLOAD_ERROR).  If the specified xpi is 
present but corrupted, then we do proceed through with installation to 
completion skipping the corrupted xpi.  The install_status.log does report the 
corrupted xpi as -207 CANT_READ_ARCHIVE.

Marking Verified!