Closed
Bug 67027
Opened 24 years ago
Closed 21 years ago
Having int chars in install folder name doesn't uninstall anything
Categories
(Core :: Internationalization, defect)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: bugzilla, Assigned: ssu0262)
References
Details
(Keywords: intl)
Attachments
(1 file, 4 obsolete files)
4.28 KB,
patch
|
dveditz
:
review+
dmosedale
:
superreview+
sspitzer
:
approval1.4b+
|
Details | Diff | Splinter Review |
If I choose to install mozilla into: c:\program files\mozillaæ.org and choose "Mozillaæ" as folder in Program Folder and then after choose to uninstall Mozilla via control panel, then nothing is uninstalled. The folder: "c:\program files\mozillaæ.org" and the Program folder "Mozillaæ" are not deleted! installer build 20010129
Changing component to Internationalization. Checked this against build 05-04-06 trunk on WinME-Ja. This build had been installed in a folder that was named using Japanese characters; choosing to uninstall via the Control Panel results in Netscape 6(6.5) being removed from the list of programs in the Add/Remove list, but nothing is actually uninstalled.
Component: Installer → Internationalization
Comment 4•23 years ago
|
||
SSU - All users should be able to uninstall the product, especially beta software. Pls accept for nsbeta.
Comment 5•23 years ago
|
||
I can't see this is a beta stopper--especially not such an old bug that wasn't even nominated until after the ramp-down has started--given the other stuff that's been thrown overboard. Mac and Linux users don't even get an uninstall.
Mac and Linux users don't need an uninstall. A lot of Windows users will not know what to do without an automatic uninstall, because of registry and dll worries. If this bug isn't fixed, we should at least include notes for uninstalling manually.
Comment 7•23 years ago
|
||
Keeoing this one on my list for those Win32 users. I will review with the PDT tomorrow or Friday.
Comment 8•23 years ago
|
||
As good citizens, we need to do a good job of cleanup, especially for a beta.
Comment 9•23 years ago
|
||
Per i18n meeting with PDT this afternoon, this is a RTM stopper, but not a beta stopper. SSU - Pls assign the milestone M0.9.2 for this one.
Assignee | ||
Comment 10•23 years ago
|
||
moving this over to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 11•23 years ago
|
||
SSU - Can we get a nsBranch on this one?
Assignee | ||
Comment 12•23 years ago
|
||
I just took a quick look at where the problem might be coming from. The solution does not look trivial. Still looking though...
Comment 13•23 years ago
|
||
AndreasB/Msanz - What's your take on this one? I think some international users might users extended or double-byte characters for their install folder. SSU - Any idea on how long this will take to fix, yet?
Comment 14•23 years ago
|
||
We need input from Sean as to how difficult it is to fix it. I agree it's very ugly and undesirable, but at this late in the game we may have to defer it. In any case, Sean, please advise.
Assignee | ||
Comment 15•23 years ago
|
||
Assignee | ||
Comment 16•23 years ago
|
||
the attached patch does fix this particular bug, but might create other problems for other character sets. I'll let Dan explain the consequences since he understands this much better than I do.
Comment 17•23 years ago
|
||
The toString() on install queue objects returns char*, which gets blindly expanded to double-bytes and passed around as pseudo-Unicode. The intent was to do an honest conversion to Unicode and then store the data in lossless UTF8. But since that's not happening any time soon (it's a big change) Sean's patch to do lame Unicode->ASCII by byte stripping turns out to successfully reconstruct the correct file name. Two wrongs *do* make a right, apparently
Comment 18•23 years ago
|
||
r=dveditz
Comment 19•23 years ago
|
||
Looks like we have a patch, and R? Thanks Dan and Sean. Can we get a SR?
Comment 20•23 years ago
|
||
rs=mscott
Assignee | ||
Comment 21•23 years ago
|
||
Jaime, you need to lobby for PDT+ for this bug to be checked into the branch. I can't check in to the branch without it.
Comment 22•23 years ago
|
||
Trying, but the CLayton is concerned about this comment by you, "but might create other problems for other character sets." Should we see how it does on the trunk, so we can assess the risk? What's your feeling on this one? How risky is it?
Assignee | ||
Comment 23•23 years ago
|
||
adding dveditz. I'll let him try to explain your concern.
Comment 24•23 years ago
|
||
This patch won't cause any additional problems. It also doesn't fix the fundamental brokenness in the nsInstallObject API. It does band-aid the situation in this particular case.
Comment 25•23 years ago
|
||
so, we can summarize saying that this is a safe fix? If so, I will send the mail to PDT. Let me know.
Comment 26•23 years ago
|
||
soudns like that is what dan is saying to me. maybe, we sound let it hang out on the trunk for a while, before we have it checked into the branch . . . just a suggestion.
Comment 28•23 years ago
|
||
Tested this using 07-17-07-trunk build on WinMe-Ja. Uninstall sometimes still does not work, depending on the chars. used in the folder name. In all cases, uninstall removes "Netscape 6 (6.1b1)" from the Add/Remove Programs list. Also, the program icons always successfully get removed from the Start menu. But depending on the chars used, the program files sometimes still remain in the install folder. I originally tested this using ????????????? for the folder name; files remained in the install folder after uninstall, so I then tested using variations of this name and single-byte numbers. I narrowed down the problem chars to the following: Program files remain when install folder contains these chars: ? (double-byte 7) ? (double-byte 1) ? (katakana "ku") All program files were successfully removed when the install folder contained only these chars (singly or combined): ? (kanji "gatsu") ? (kanji "nichi") ? (hiragana "no") ? (katakana "to") ? (katakana "ra") ? (katakana "n") ? (katakana "bi") ? (katakana "ru") ? (katakana "do") ? (kanji 7 "shichi") 1 (single-byte 1) 7 (single-byte 7)
Comment 29•23 years ago
|
||
Sorry, that looks like my chars didn't get encoded properly. Let's try that again: The original folder: $B#77n#1#7F|$N%H%i%s%/%S%k%I(B Program files remain when install folder contains these chars: $B#7(B (double-byte 7) $B#1(B (double-byte 1) $B%/(B (katakana "ku") All program files were successfully removed when the install folder contained only these chars (singly or combined): $B7n(B (kanji "gatsu") $BF|(B (kanji "nichi") $B$N(B (hiragana "no") $B%H(B (katakana "to") $B%i(B (katakana "ra") $B%s(B (katakana "n") $B%S(B (katakana "bi") $B%k(B (katakana "ru") $B%I(B (katakana "do") $B<7(B (kanji 7 "shichi") 1 (single-byte 1) 7 (single-byte 7)
Comment 30•23 years ago
|
||
SSU/Ftang - I liked to TM this one for 0.9.4, if possible (i.e. eMojo release).
Comment 32•23 years ago
|
||
Fixing the underlying problem (and some other installer i18n problems) as opposed to the band-aid "two wrongs make a right" hack we stuck in here will take some significant work, from an install staff of one. Unlikely to be improved for 0.9.4 given other more pressing problems.
Assignee: ssu → syd
Status: ASSIGNED → NEW
Comment 33•23 years ago
|
||
Dan - I understand, band-aid "two wrongs make a right" , but its the only thing we have in the short term. Shouldn't we fix the problem for the user ASAP, and then fix it, the better way later? I'd hate to see tthe work already done slip to the side, and this issue not addressed for an indefinite amount of time (i.e. The right fix, might not make your planned list of work for the next couple of releases).
Comment 34•23 years ago
|
||
The band-aid proposed here has been checked into the tree (trunk and branch), and it goes a long way toward solving the problem. I can't think of an additional band-aid to fix the remaining problems described, we'll have to go for the complete restructuring to do that.
Comment 35•23 years ago
|
||
Ah! Should we close this one based on its summary, and open other bugs for the other related issues?
Comment 36•23 years ago
|
||
"Doesn't uninstall anything" doesn't seem to apply anymore. Even when problematic chars are used in the folder name, it looks like everything but the program files are getting removed (registry entries get removed also). I'll write a new bug if everyone agrees that's the way to go.
Comment 37•23 years ago
|
||
Added this to the RTM Branch Release Notes Tracking bug (bug 90577).
Comment 39•23 years ago
|
||
The original problem seems to have returned. In 07-27-branch US (on WinMe-Ja), I cannot uninstall anything if the install folder contains Japanese chars. In my comments on 7-17, I said that certain chars do not cause a problem; this no longer is the case. The only thing that gets removed is the entry in "Add/Remove Programs"; everything else remains, including the Start Menu icons.
Comment 40•23 years ago
|
||
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → ruixu
Comment 41•23 years ago
|
||
Moving to 0.9.5, getting rid of keyword soup
Comment 42•23 years ago
|
||
Marking nsbranch- as it was decided in the August bug triage that we wouldn't have enough time in eMojo to fix this. Let's revisit for MachV.
Keywords: nsbranch-
Comment 43•23 years ago
|
||
removed keyword nsbranch since it now has nsbranch-, per pdt mtg.
Keywords: nsbranch
Comment 44•23 years ago
|
||
--> I forget who is doing install on Sol's team.
Comment 45•23 years ago
|
||
GreggL is PM for installer. Question - must the user change the default installation location in order to see the effects of this bug?
Comment 46•23 years ago
|
||
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 47•23 years ago
|
||
Can someone hint to as what the rewrite to better support i18n would entail?
Keywords: nsbeta1
Target Milestone: mozilla0.9.6 → ---
Comment 49•22 years ago
|
||
nsbeta1- ADT/XPInstall triage.
Comment 50•22 years ago
|
||
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the list if it doesn't even rate adt3.) Thanks!
Updated•22 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 51•22 years ago
|
||
See also bug 137656.
Keywords: mozilla1.0.1
Summary: Having int chars in install folder name doesnt uninstall anything → Having int chars in install folder name doesn't uninstall anything
Assignee | ||
Comment 52•21 years ago
|
||
Comment 53•21 years ago
|
||
Comment on attachment 122083 [details] [diff] [review] patch v2.0 r=dveditz
Attachment #122083 -
Flags: review+
Comment 54•21 years ago
|
||
Sean is writing patches for this, over to him
Assignee: curt → ssu
Status: ASSIGNED → NEW
Assignee | ||
Comment 55•21 years ago
|
||
In addition to fixing this bug, this patch might also fix bug 137656.
Attachment #122083 -
Attachment is obsolete: true
Attachment #122419 -
Flags: review?(dveditz)
Attachment #122419 -
Flags: review?(dveditz)
Assignee | ||
Comment 56•21 years ago
|
||
Attachment #122419 -
Attachment is obsolete: true
Comment 57•21 years ago
|
||
Comment on attachment 122469 [details] [diff] [review] patch v2.2 r=dveditz
Attachment #122469 -
Flags: review+
Attachment #122469 -
Flags: superreview?(jaggernaut)
Comment 58•21 years ago
|
||
Comment on attachment 122469 [details] [diff] [review] patch v2.2 sr=jag
Attachment #122469 -
Flags: superreview?(jaggernaut) → superreview+
Assignee | ||
Comment 59•21 years ago
|
||
Comment on attachment 122469 [details] [diff] [review] patch v2.2 more string cleanup stuff. not regression. Tested on a JA XP machine to make sure it worked.
Attachment #122469 -
Flags: approval1.4b?
Comment 60•21 years ago
|
||
Comment on attachment 122469 [details] [diff] [review] patch v2.2 a=sspitzer
Attachment #122469 -
Flags: approval1.4b? → approval1.4b+
Assignee | ||
Comment 61•21 years ago
|
||
previous patch causes crash under a true JA system. this one does not, and also fixes the uninstaller problem.
Attachment #122469 -
Attachment is obsolete: true
Attachment #122528 -
Flags: superreview?(jaggernaut)
Attachment #122528 -
Flags: review?(dveditz)
Comment 62•21 years ago
|
||
Comment on attachment 122528 [details] [diff] [review] patchv 2.3 r=dveditz Please comment the AssignWithConversion() in ::OnFinalizeProgress that the apparently Lossy conversion is safe because the input source came from a similar fake-ascii-to-not-really-unicode conversion.
Attachment #122528 -
Flags: review?(dveditz) → review+
Comment 63•21 years ago
|
||
Comment on attachment 122528 [details] [diff] [review] patchv 2.3 sr=dmose@mozilla.org
Attachment #122528 -
Flags: superreview?(jaggernaut) → superreview+
Assignee | ||
Comment 64•21 years ago
|
||
Comment on attachment 122528 [details] [diff] [review] patchv 2.3 trivial fix. already tested in a JA winXP system.
Attachment #122528 -
Flags: approval1.4b?
Comment 65•21 years ago
|
||
Comment on attachment 122528 [details] [diff] [review] patchv 2.3 a=sspitzer
Attachment #122528 -
Flags: approval1.4b? → approval1.4b+
Assignee | ||
Comment 66•21 years ago
|
||
patch checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 67•21 years ago
|
||
Verified fixed on 05-06 trunk build on WinXP-JA, Win98-JA with Japanese characters and Win2000-EN , Win98-German with Latin 1 accent characters.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•