Build: 10/4/99 SeaMonkey build 1. From http://jimbob/trigger2.html, trigger http://jimbob/jars/a_fileop_dirrename.xpi 2. A directory is created and renamed 3. Repeat step #1 to attempt renaming a directory that already exists Install.StartInstall("Acceptance: a_fileop_dirrename", "acceptance", "1.1.1.1", 0); f = Install.GetFolder("Program", "a_fileop_dirrename"); err1 = Install.DirCreate(f); Install.LogComment("DirCreate returns = " + err1); err2 = Install.DirRename(f, "a_fileop_renamed"); Install.LogComment("DirRename returns = " + err2); RESULT: The directory, a_fileop_renamed, already exists when step #3 above is attempted. It appears that directory, a_fileop_dirrename, is not renamed (from step #3) since one by this name already exists. But the install.log indicates that the renaming does take place shown by the following example: --------------------------------------------------------------------------- http://jimbob/jars/a_fileop_dirrename.xpi -- 10/04/1999 14:30:17 --------------------------------------------------------------------------- Acceptance: a_fileop_dirrename ------------------------------ ** DirCreate returns = 0 ** DirRename returns = 0 Item [1/2] Create Folder: C:\Program Files\moz104\x86rel\a_fileop_dirrename\ Item [2/2] Rename Dir: a_fileop_renamed Install completed successfully Finished Installation 10/04/1999 14:30:18 EXPECTED RESULT: The Install.log should not show: Item [2/2] Rename Dir: a_fileop_renamed or an error message should be returned to indicate that the renaming did not occur.

DirRename should check during Prepare() to see if the target name is already taken by an existing file/directory, and maybe some checking to see if it'll be on a different file system or write permissions or whatever other errors we can think might occurr. If an error occurrs during Complete() I'd lean toward returning it and aborting the install -- who knows, it could be a crucial configuration directory. Basically we need a spec for these objects.

I agree that it should stop if there's an error during finalize(). I don't think it is necessary to check during prepare if it already does it in complete(). I just tried it, and it seems to be working properly now. It returns a -201 error (unexpected error). Marking this fixed. Please reopen this bug if a check is really necessary during the prepare() phase.

adding dvetiz@netscape.com to CC.

Checking as much as possible during Prepare() is crucial! Failing during Finalize is a disaster since it could leave things partially installed.

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

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

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