User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a ; ..:: Ar't ::..) Gecko/20030323 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a ; ..:: Ar't ::..) Gecko/20030323 instaling xpi again, create *.old files (in this package) in place orginal mnenhy.jar -> mnenhy.old fresh install# ls mnenhy.jar instaling again# ls mnenhy.old and again# ls mnenhy.jar mnenhy.old Reproducible: Always Steps to Reproduce: 1. install any xpi package eg from mozdev.org 2. install it again 3. Actual Results: new files deleted and only old exist Expected Results: old files replacing by new

yes. *.old files are created

The actual problem is with the nsLocalFile implamentation. It's either broken on unix or broken on osx and win32. Per my conversation with darin, this patch should take into account the nsLocalFile discrepency between platforms. He will be fixing nsLocalFile to do the right thing (which will not affect this patch). Here's what the problem was: nsLocalFile's MoveToNative() function sets the object that was moved to the new named that it was moved to. It was not doing this under unix, only under OSX and win32. Darin and I think that unix is correct and will be fixing the other platforms to match (see bug 2000024).

(1) It appears to me that mac and windows behave as a developer would expect: if I ask for a file to be moved, the file object's parent folder and leaf name should reflect the new location (move destination). There is little value and it seems to me it would be unexpected that the file object does not maintain the state of its current location. Am I missing something? (2) If (1) holds then the fix would be to change the unix behavior to comply with mac and windows. That change would obviate the need to SetLeafName() as you are doing after each MoveToNative(). XPInstall would not need to be changed, nsLocalFileUnix would. So the pending question is: who relies on the unix behavior of MoveToNative() and are they suffering from divergent operational semantics across platforms? Also, why is this a new bug? What code changed recently to cause this?

It's hard to say who relies on the current Unix behavior. Xpinstall definitely didn't before, and I don't know when this changed. I can't easily tell from cvs blame.

Comment on attachment 119025 [details] [diff] [review] patch v1.0 >+ rv = renamedDoomedFile->SetNativeLeafName(uniqueLeafName); seems like these should be #ifdef XP_UNIX given the comment. no?

I chose not to because when bug 2000024 is fixed, win32 and osx will have this exact problem.

Comment on attachment 119025 [details] [diff] [review] patch v1.0 er, ok... but when that bug is fixed, we'll want to rev this code anyways to at least clean up the comments. r=darin

*** Bug 202973 has been marked as a duplicate of this bug. ***

bug 202973 was given 1.4b+ just before it was duped against this one, so I'm carrying it forward. I'd like to point out though, that from what I saw today, installing venkman a third or fourth time did *not* make venkman show up. This bug suggests that it should, and I noticed that it used to, but not anymore. Perhaps there is another regression here.

yes. this bug does suggest that installing it a 3rd/4th time does get you the original filename. I'll test this again in the morning to make sure it fixes bug 202973.

Comment on attachment 119025 [details] [diff] [review] patch v1.0 sr=dmose@mozilla.org

The patch does fix bug 202973. I just tested it with a debug build built last night. The reason it's not leaving the original filenames on the 3rd/4th install is probably because the files in question are in use, which is different from my test cases. I don't see 'approval1.4b' in the edit patch page. I wonder how approvals are given out these days...

Comment on attachment 119025 [details] [diff] [review] patch v1.0 a=asa (on behalf of drivers) for checkin to 1.4b.

patch checked in.

verified on build 2003042505

This works for me now too. Thanks for the fix.