Closed Bug 37842 Opened 24 years ago Closed 24 years ago

2nd file installs (w/ "-1" ext) & indicates "restart required" in logfile (Linux)

Categories

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

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Platform:
All
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: depman1, Assigned: mscott)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta2-][nsbeta3+]) 

linux only. build 2000-05-01-11-M16.
1. Go to http://jimbob/trigger3.html
2. Select either a_getfolder_unix_fileurl or a_getfolder_2_temporary from the 
acceptance test case menu.
3. Trigger. OK
4. Check logfile.
Result: Indicates "restart required" after successful install.

logfile:

-------------------------------------------------------------------------------
http://jimbob/jars/a_getfolder_unix_fileurl.xpi  --  05/01/2000 18:35:00
-------------------------------------------------------------------------------

     Acceptance: a_getfolder_unix_fileurl
     ------------------------------------

     [1/1]	Replacing: /tmp//smrtupdt.txt

     Install completed successfully, restart required
     Finished Installation  05/01/2000 18:35:00
This happens when triggering a 2nd time. Instead of replacing the unlocked file, 
it creates another file with "-1" extension. This happens with XPIs using 
addFile(). Try a_addfile_full_iver_ver.xpi, for example. In the log, we'll see 
"restart required".
QA Contact: jimmylee → depstein
Summary: Couple of getFolder() xpi indicate "restart required" in logfile → 2nd file installs (name-1) & indicates "restart required" in logfile (Linux)
Summary: 2nd file installs (name-1) & indicates "restart required" in logfile (Linux) → 2nd file installs (w/ "-1" ext) & indicates "restart required" in logfile (Linux)
Added "pp" to Keywords.
Keywords: pp
regression from PR1, must fix in PR2
Assignee: ssu → dougt
Keywords: nsbeta2
Target Milestone: --- → M17
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
xpinstall bugs to dveditz.
Assignee: dougt → dveditz
Reassigning to Don for load balancing
Assignee: dveditz → dbragg
Well, through a roundabout way (involving the incredibly user-friendly UNIX 
debugger), I figured out the cause of this bug.  MoveTo is not implemented on 
Unix, thus the regression. <sigh>  Guess I should have checked LXR first eh?
Status: NEW → ASSIGNED
This needs to be reassigned to person(s) responsible for xpcom/io. Specifically
nsLocalFileUnix.
Hardware: PC → All
What's the user visible impact of this bug?  Do we retrigger in the installer?
I don't think so.  The only thing I can think of is if the user retriggers from
the SmartUpdate page, and then the worst thing that happens is that they get
told they need to restart.

Removing nsbeta2+ for reconsideration.
Whiteboard: [nsbeta2+]
We need to consider if we need this functionality in for Beta3.  If we are going 
to replace files going from Beta2 to Beta3, then we need this in.  Windows and 
Macintosh already support this ability.

I hope that we can exercise more of our XPInstall APIs going from Beta2 to Beta3 
for broader test coverage.  If we do not plan to use xpi upgrades going from 
Beta2 to Beta3, then it seems reasonable that we do not need this fix for Beta2.
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Reassigning to Blizzard for implementation of nsIFile.MoveTo on Unix (a subset 
of bug 17948)
Assignee: dbragg → blizzard
Status: ASSIGNED → NEW
Depends on: 17948
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA 7/14
ETA 7/14 can't be true any more, can it?
Forgot about this one. Could this be the cause of bug 45716?
This is partly the cause of 45716.  But 45716 is deeper as I have documented 
there.  
Per todays Eng Mgr triage, mocing from [nsbeta2+] to [nsbeta2-]
Whiteboard: [nsbeta2+] ETA 7/14 → [nsbeta2-] ETA 7/14
QA nominating for beta3.

Files cannot be replaced and cleaned up properly.
Keywords: nsbeta3
Dan,
Can we approve this for nsbeta3?  This hoses are upgrade story on Unix.
Whiteboard: [nsbeta2-] ETA 7/14
Oops.  I meant "This hoses *our* upgrade story."  :o)
Don't remove old nsbeta2- notations, it screws up the queries. (nsbeta2 
nominations without a nsbeta2+/- are flagged as potential respin candidates), 
just nominate for nsbeta3. Unfortunatel

Really the one we want fixed is 17948 -- that's the one to nominate (this one 
too, but that one's the real fix).

I do not have the authority to approve bugs for people outside our own team, we 
need to get PDT approval. Since Blizzard does not work for Netscape a nsbeta3+ 
is not very binding and we may have to seek someone else to fix this. (dougt? 
it's all his fault anyway :-) )
Whiteboard: [nsbeta2-][nsbeta3+]
mass assign
Status: NEW → ASSIGNED
Doug says he fixed linux MoveTo -- David could you please re-check this one to 
see if that was a sufficient change?
Ran the mozilla-installer twice with the same target directory.  No "made 
unique" files were left around.  mscott fixed this by implementing MoveTo() on 
Unix and in fact it looks like it went into PR2!  Thanks mscott!
Assignee: blizzard → mscott
Status: ASSIGNED → NEW
I think we can close this bug out.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
fixed in Linux build 2000-08-28-11-M17. Files update correctly.
Status: RESOLVED → VERIFIED
oops. I mean M18.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.