15603 - File op: Install.log incorrectly informs that file copy to unknown dir is successful

Status: VERIFIED FIXED

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

Description

[Jimmy Lee]

Build: 10/4/99 SeaMonkey build

1. From http://jimbob/trigger2.html, trigger
   http://jimbob/jars/f_fileop_filecopy_unknowndir.xpi

Install.StartInstall("Functional: f_fileop_filecopy_unknowndir",
"f_fileop_filecopy_unknowndir", "1.1.1.1", 0);
f = Install.GetFolder("Program");
g = Install.GetFolder("Chrome");
err1 = Install.AddSubcomponent("fileop_filecopy_unknowndir", jarSrc, f, jarSrc);
Install.LogComment("AddSubcomponent returns = " + err1);

fileSource = f + "/smrtupdt.txt";
fileTarget = g + "/unknowndir/";
err2 = Install.FileCopy(fileSource, fileTarget);
Install.LogComment("FileCopy returns = " + err2);

RESULT:
The file is not copied to the unknown directory as expected.  However, the
Install.log shows the following:

---------------------------------------------------------------------------
http://jimbob/jars/f_fileop_filecopy_unknowndir.xpi   --   10/05/1999 12:39:05
---------------------------------------------------------------------------

     Functional: f_fileop_filecopy_unknowndir
     ----------------------------------------

     ** AddSubcomponent returns = 0
     ** FileCopy returns = 0
     Item [1/2]	Installing: C:\Program Files\moz104\x86rel\smrtupdt.txt
     Item [2/2]	Copy File: C:\Program Files\moz104\x86rel\smrtupdt.txt to
                           C:\Program Files\moz104\x86rel\chrome\unknowndir

     Install completed successfully
     Finished Installation  10/05/1999 12:39:05

EXPECTED RESULT:
The Install.log does not indicate that the file was copied since it did not
actually occur.

Comment 1

[Daniel Veditz [:dveditz]]

So fileCopy supports a directory as the target? Can we pull this off on all
systems? Maybe we should require both arguments to be file names.

This item is one which can probable best be done during the Prepare() stage so
we can return an error in time for the user to deal with it. Copy to a temp
name just in case an old file of the target name exists already. If the copy
item fails during Complete() (really just a rename at this point, or schedule
for rename later) we should return an error and abort the rest of the install
-- we have no way of knowing how crucial the copied file is to the correct
operation of the installed software.

Comment 2

[Sean Su]

This has been fixed when I overhauled the fileop functions to better detect and
deal with errors.

Comment 3

[Jimmy Lee]

Build 1999-10-27-09-M11(WIN), 1999-10-27-08-M11(MAC), 1999-10-27-08-M11(LINUX)

We correctly error out now with -214.

Comment 4

[leger]

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine