6410 - [BLOCKED][DOGFOOD][PP]scheduling replacement of a file doesn't work

Status: VERIFIED FIXED

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

Description

[Cathleen]

During file replacement stage, replacing a read only file will fail, thus the
task is scheduled to perform at next startup time.

As a scheduled task, there is some problem about replacing the old file.

Comment 1

[Doug Turner (:dougt)]

I believe that I fixed this.  cathleen can you verify?

Comment 2

[Cathleen]

this should be fixed.

Comment 3

[Jimmy Lee]

Build 9/22/99

This works for Linux (9/16/99) and Windows, but Macintosh is still a problem.

1. From http://jimbob/trigger2.html, click on drop-down button and choose
   f_addsubcomp_macsmpltxt and click Trigger case button
2. Lock this installed file (or launch it so it is running and in use)
3. From http://jimbob/trigger2.html, click on drop-down button and choose
   f_addsubcomp_macsmpltxt_inus and click Trigger case button

Install.StartInstall("Functional:f_addsubcomp_macsmpltxt_inus",
"f_addsubcomp_macsmpltxt", "1.0.1.5", 1);
f = Install.GetFolder("Program", "simpletext_subdir");
Install.AddSubcomponent(regName, "1.0.1.5", jarSrc, f, jarSrc, true);

RESULT:
From the directory simpletext_subdir, the second installation created a file
named "decode" (126K).  The first installation still shows file, SimpleText
(63K).

EXPECTED RESULT:
The 63K version of SimpleText is replaced by the 126K version of SimpleText.

Comment 4

[leger]

Clearing Fixed resolution due to reopen.

Comment 5

[Cathleen]

needs to get fixed by beta.

Comment 6

[Doug Turner (:dougt)]

this bug is blocked until dveditz fixes 6986.

Comment 7

[Doug Turner (:dougt)]

assigning to dan per eng meeting

Comment 8

[leger]

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

Comment 9

[Jimmy Lee]

Build 1999-12-10-08-M12(MAC)

From my example described from 9/22/99, the RESULT now shows SimpleText-1 as
63K.  It appears that the 128K version did not replace the existing 63K file.

Comment 10

[Jimmy Lee]

The 12/10/99 builds for Linux and Windows are still behaving as expected.

Comment 11

[Daniel Veditz [:dveditz]]

This would break the update.html page if true. Anyone tested that?

Can someone on the XPInstall team with a Mac look at this? If this is true and
the update page is broken then this could be a M12 stopper (preventing PSM
install when available)

I am suspicious, however, that older descriptions talk about the "SimpleText"
file while the latest says "SimpleText-1" -- sounds to me like the file got
replaced and maybe the old one just didn't get deleted. Did you restart
mozilla to run the "clean-up" portion?

Comment 12

[Samir Gehani]

It doesn't appear to work on the Mac. In fact, the symptom makes the problem
pretty obvious.

1> Installed the "AddSubcomponent" testcase from puma/x.
2> The file ascSmartUpdate.txt was installed in the program folder.
3> Locked the file through the Finder.
4> Triggered the same JAR.
5> A second file: ascSmartUpdate.txt-1 was installed.
6> Shutdown Mozilla.
7> Unlocked the first file: ascSmartUpdate.txt
8> Restarted Mozilla.
9> Both files still stayed: ascSmartUpdate.txt and ascSmartUpdate.txt-1. and no
replacement occured, apparently.

But, wait! My program folder (one level above the initial installation) has been
renamed ascSmartUpdate.txt. Looks like we are tacking on an extra colon
somewhere in the file replacement algorithm. Don't have a recent Mac build to
fix this yet.

Dan,
Reassign this to me if you'd like me to fix it. The problem seems straight
forward enough to possibly fix from another platform (if the extra colon is
apprent), though.

Comment 13

[Daniel Veditz [:dveditz]]

Reassigning to Samir. Since replacement files are stored as
platform-dependent "persistent file descriptors" I doubt this could be debugged
anywhere but on a Mac.

Put breakpoints in the file ScheduledTasks.cpp -- that is where files are both
stored and then retrieved from the registry at startup.

Comment 14

[Samir Gehani]

For binaries held open the behavior is different.

1> Installed SimpleText in the program folder. FinalizeInstall returns 0.
2> Launch and leave open the installed copy of SimpleText.
3> Run the same xpi to try and install SimpleText over the open copy.
FinalizeInstall returns -201 and renames the running copy to SimpleText-1.

So, we have two bugs here: one for open binaries and the other for locked files.
Replacement in both cases is failing and the behavior is different.

Comment 15

[Daniel Veditz [:dveditz]]

Moving target for resurrected bug

Comment 16

[leger]

Clearing FIXED resolution due to reopen.

Comment 17

[Samir Gehani]

Fix in hand. Awaiting code review.

Comment 18

[Samir Gehani]

Fix checked in.

Comment 19

[Jimmy Lee]

Build 1999-12-14-08-M12(MAC)

Well, we correctly schedule and cleanup after when a file was in use.  However,
we are still having a problem when a file has been locked.

Marking Verified because the DOGFOOD part is fixed.  I will open a new bug
specifically addressing this non-DOGFOOD case for locked files which is specific
to the Mac only.