43226 - File.dirRename isn't working on Linux and Win.

Status: RESOLVED WONTFIX

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

Description

[David Epstein]

builds: linux, Win98 & NT: 2000-06-20-08-M17. Works fine on Mac.
1. Go to http://jimbob/trigger3.html
2. Select a_fileop_dirrename from Acceptance test case menu.
3. Trigger. OK.
4. Check hard drive and logfile.

Results:
Linux: Directory is not renamed. Get -201 error (and junk chars returned for 
File.dirRename) in logfile.
Win: Original directory remains ("a_fileop_dirrename"), and renamed one is also 
created ("a_fileop_renamed"). No error, but junk chars returned for File.dirRen

Expected:
Directory renamed to "a_fileop_renamed". No errors or junk chars in logfile.

log file:

-------------------------------------------------------------------------------
http://jimbob/jars/a_fileop_dirrename.xpi  --  06/20/2000 16:03:21
-------------------------------------------------------------------------------

     Acceptance: a_fileop_dirrename
     ------------------------------

     ** dirCreate returns = 0
     [1/1]	Create Folder: /u/depstein/builds/M17/jun20/./a_fileop_dirrename

     Install completed successfully
     The Directory Rename part
     -------------------------

     ** dirRename returns = 0
     [1/1]	˜81@˜81@Ð;¬‰ˆˆ=

     Install **FAILED** with error -201

     Install **FAILED** with error -201
     Finished Installation  06/20/2000 16:03:22

Comment 1

[David Epstein]

changed qa contact to depstein. nominated nsbeta2 because it's a regression 
test.

Comment 2

[leger]

Putting on [nsbeta2-] radar per today's beta2 XP Install PDT review.

Comment 3

[David Epstein]

nominated by QA for nsbeta3. This is breakage of a key fileop API. On Linux, 
directory doesn't rename. On Win, it mistakenly acts like a directory copy: the 
original directory remains while a new one is created with the new name.

Comment 4

[Daniel Veditz [:dveditz]]

We could drop this one if we have to, but accepting for now.

Comment 5

[Daniel Veditz [:dveditz]]

Not crucial functionality, nsbeta3-

Comment 6

[Jimmy Lee]

Updating QA Contact.

Comment 7

[Jimmy Lee]

Nominating.

Comment 8

[dprice (gone)]

adopting

Comment 9

[dprice (gone)]

Traced this down to a call to nsLocalFile::MoveTo  Looks like the windows
portion of this bug is a dup of   
http://bugzilla.mozilla.org/show_bug.cgi?id=101527
Marking it as a blocker

Comment 10

[Jimmy Lee]

We can live with nsbeta1- :-(

Comment 11

[Syd Logan]

Resetting milestone of all nsbeta1-bugs, only nsbeta1+ bugs should have a target
milestone.

Comment 12

[Syd Logan]

Resetting milestone, only nsbeta1+ bugs can have a milestone on them, these are
niminated, but not yet plussed.

Comment 13

[David Epstein]

You can now trigger this test case from
http://www.mozilla.org/quality/smartupdate/xpinstall-trigger.html
Just select a_fileop_dirrename from the Acceptance menu.
Should this bug be reassigned?

Comment 14

[Daniel Veditz [:dveditz]]

The xpinstall script engine has been removed from the trunk, bugs in it are obsolete.