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.

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

this should be fixed.

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.

Clearing Fixed resolution due to reopen.

needs to get fixed by beta.

this bug is blocked until dveditz fixes 6986.

assigning to dan per eng meeting

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

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.

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

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?

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.

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.

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.

Moving target for resurrected bug

Clearing FIXED resolution due to reopen.

Fix in hand. Awaiting code review.

Fix checked in.

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.