Closed Bug 15424 Opened 21 years ago Closed 18 years ago
old versions of files that were renamed after migration should be removed
Old preferences.js file is not used and it's placement into the new profile directory is confusing and misleading. We should make this live in "old" directory, or pick another name that says "here's the old one, just FYI".
21 years ago
Status: NEW → ASSIGNED
OS: Linux → All
Summary: Old preferences.js file should live in "old" directory → old versions of files that were renamed after migration should be removed.
this is a more general bug, for all platforms. accepting.
Reassign to dbragg
Oops, never marked "assigned". Accepting.
moving to M16
Target Milestone: M15 → M16
dbragg is on sabatical. assigning to cathleen for re-delegation.
Assignee: dbragg → cathleen
Status: ASSIGNED → NEW
reassigning to doug. :-)
Component: Profile Migration → Installer: XPInstall Engine
QA Contact: gbush → jimmylee
wrong mass change. reassign to dbragg, and set target milestone to M17
Assignee: cathleen → dbragg
Target Milestone: M16 → M17
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.
Grace: Isn't this more of a XPInstall: XPI Packages bug?
I think it is a profile migration issue....how did it get here? changing QA contact too.
Component: Installer: XPInstall Engine → Profile Migration
QA Contact: jimmylee → gbush
Resetting missed milestones
Target Milestone: M17 → ---
Reassigning profile migration bugs to the current owner
Assignee: dbragg → racham
Status: ASSIGNED → NEW
Except for preferences.js , other old version files should also be deleted, such as some old address book (*.dat).
Can this bug assigned to me? Let me try to solve it.
Hope this patch can solve this problem. Instead of deleting the files unused, this patch solve this problem by just copying the files needed. r= wanted
Can anyone take a look at this bug and review the patch? Thanks.
Comment on attachment 77803 [details] [diff] [review] patch for review I like the idea but this has a problem (at least on Mac) >+#define PSM_CERT7_DB "cert7.db" >+#define PSM_KEY3_DB "key3.db" >+#define PSM_SECMODULE_DB "secmodule.db" These files are actually named "Certificates7" "Key Database3" "Security Modules" and, they are located in a subdir within the profile dir called "Security" Not that I agree with that inconsistency with other platforms but it has to be here unless PSM is changed.
Attachment #77803 - Flags: needs-work+
Thanks, Conrad Carlen. According to your suggestion, I give a new patch. Can you or anyone else review it?
Attachment #77803 - Attachment is obsolete: true
Can anyone review this bug? Thanks.
Sorry to wait so long to review - somehow I missed this :-/ On the XP_MAC part, instead of these 3 copies: >+ rv = DoTheCopy(oldSecurityPath, newSecurityPath, PSM_CERT7_DB); >+ if (NS_FAILED(rv)) return rv; >+ rv = DoTheCopy(oldSecurityPath, newSecurityPath, PSM_KEY3_DB); >+ if (NS_FAILED(rv)) return rv; >+ rv = DoTheCopy(oldSecurityPath, newSecurityPath, PSM_SECMODULE_DB); >+ if (NS_FAILED(rv)) return rv; why not just copy the "Security" dir in one call to DoTheCopy()? If so, the whole, large XP_MAC block would reduce to: rv = DoTheCopy(oldProfilePath, newProfilePath, SECURITY_PATH);
We just need the three files and not all the contents in the security path(SECURITY_PATH), right?
> We just need the three files and not all the contents in the security path(SECURITY_PATH) Looking in my 4.x profile dir, those three files *are* the only contents of SECURITY_PATH.
Yes. They should be the only ones. :) I just mean that the user may backup these files in the same directory, such as "Certificates7.bak" for "Certificates7" or something like that, and they are not what we want. In these cases, we just need copy the three files and not the others. Right?
Hi, Conrad Carlen, can you or anyone else review the patch 79784 for this bug again? Thanks.
Can anyone take a look at the patch for this bug? :< Thanks Henry
About comment 22 and 23: In terms of extra files in the "Security" dir - I think it's a rare but harmless case and not worth bulking up the code to avoid it.
Hi, Conrad Carlen, The goal of this bug is to make the directories clean. We just migrate what we need. Though it may be rare and harmless that there are extra files in the "Security" dir, I still think we should try to avoid the extra files. Your opinion? Henry
According to Conrad Carlen's idea, I give out this new patch to make the code more compact. Thanks, Conrad Carlen. Pls review it.
Attachment #79784 - Attachment is obsolete: true
Let me take care of this bug, add email@example.com to the CC list.
Let me take care of this bug, add firstname.lastname@example.org to the CC list.
Assignee: racham → Henry.Jia
Comment on attachment 87493 [details] [diff] [review] patch with compact code r=ccarlen. How any platforms has this been tested on?
Attachment #87493 - Flags: review+
ccarlen, I tested also on Windows and find a error in the previous patch. Mozilla uses secmod.db instead of secmodule.db on windows. Now, I've tested on windows and unix. And you have checked on Mac. So, this patch should be OK. Pls r= it again. Just a line changed. - #define PSM_SECMODULE_DB "secmodule.db" + #define PSM_SECMODULE_DB "secmod.db" Thx.
Attachment #87493 - Attachment is obsolete: true
Comment on attachment 88107 [details] [diff] [review] patch with a line change r=ccarlen
Attachment #88107 - Flags: review+
Comment on attachment 88107 [details] [diff] [review] patch with a line change sr=scc. platform specific file names seem like the major hindrance here. Make sure this patch gets adequate testing on appropriate systems before checking in
Attachment #88107 - Flags: superreview+
Patch landed. Marking fixed.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
I can verify this for Mozilla only- fix not in commercial Conrad, should this be for Mozilla only- should I reopen if not- or open another bug in bugscape?
I don't think we should reopen this one. It's fixed in trunk.
The issue isn't trunk or not - it's mozilla vs. commercial. If this is verified as working for mozilla, close it out and file a bugscape bug for commercial.
verifying for Mozilla Please open new bug in Bugscape if wanted for commercial builds
Status: RESOLVED → VERIFIED
Apply for a= for branchOEM
Whiteboard: [nsbeta3-] → [nsbeta3-], branchOEM
I want to clarify something from Grace. Grace: You said that the bug was fixed in mozilla only and not commercial. Are you saying that some other files (older versions of files) in the commercial tree still need to be clean up? Or are you saying that this patch does not have any impact on the commercial tree (e.g., the commercial tree has a different file that needs to be modified)? Sorry that it may not be the appropriate forum to talk about commercial tree, but I am hoping that you won't mind giving me a simple answer. Thanks.
Margaret, This is not a critical bug. Should we put it in or hold for the next release? Henry
Profile Migration copies files from a Netscape 4.x profile to a Mozilla or commercial 6.x profile. Mozilla and commercial then rename some of those files for use in that app on some platforms (for instance preferences.js is renamed prefs.js on Linux) These copied files are not removed after the renaming. Henry's patch takes care of removing extraneous files on Mozilla only. The same files exist for commercial.
Thank you Grace for the explanation. I guess I still have some doubts in my mind. Let me ask it in a different way. From your explanation, I interpret it this way: Without the fix, after migration from 4.7x to MOZILLA, these old files (as an example) will be left behind: preferences.js old-version-file-1 old-version-file-2 old-version-file-3 ... With the fix, these old files will be removed. And if I understand you correctly, what you are saying is that: Without the fix, after migration from 4.7x to NETSCAPE6/NETSCAPE7, these old files will be left behind: preferences.js old-version-file-1 old-version-file-2 old-version-file-3 ... With the fix, these old files will still be there untouched. It will NOT be removed even though they have the same name as what mozilla uses. If my understanding is correct so far, that means in the commercial tree, profile migration has a different set of source code to manipulate these files. In order to remove these same set of files, we'll have to modify the source code in the commercial tree. Is that correct? I just want to understand it correctly, so that if we want these files to be removed from the commercial tree, we need to fix it over there, and not taking this fix for our commercial build. Thanks.
Whiteboard: [nsbeta3-], branchOEM+ → [nsbeta3-], branchOEM+, fixedOEM
In OEM branch. Margaret, if something wrong, let me know.
Hi Henry: I don't expect anything will go wrong here. At most, it just won't have any impact to the commercial build. You should be able to find that out in the next RE commercial build.
sorry for delay in getting back to you on this- the files copied to mozilla (or netscape 6.x) profile from a Netscape 4.x profile are the same. There may be additional files in commercial profile created by that app but not part of this bug. Thiw would be welcome in commercial tree -see bug 137600 I will leave this verified as noted before and add your names to that bug
Thank you for the clarification, Grace. This fix will at least get rid of some of the old files (if not all) then. Thanks for the cc as well.
according to cavin, this caused a regression. (but something probably only noticed for Netscape builds, and not mozilla builds) in 4.x, the addressbook files were stored at ~/*.na2, and Netscape 7.x is able to migrate those. (Mozilla 1.x is not, as the code to read .na2 files is not open source) Does SUN ship something mozilla based, or something Netscape based? (if netscape based, meaning they have access to the ns tree, their OEM branch would have the same problem.)
We ever released Netscape 7.0. Now, we are working to release a Mozilla based product. Hi, Seth, do you mean this patch affects the code of netscape private part?
this checkin also broke mozilla. for example, see bug #202010 (pop filter migration broken on linux) also broken: popstate.dat migration. on mac, filter migration is broken for imap (and maybe pop). some files that we used to copy over to the new profile folder (And then rename) are no longer getting copied over.
for the mac bug, see bug #190336
Thx for the catch.
You need to log in before you can comment on or make changes to this bug.