Closed Bug 15424 Opened 25 years ago Closed 22 years ago

old versions of files that were renamed after migration should be removed.

Categories

(Core Graveyard :: Profile: Migration, defect, P3)

Product:
Core Graveyard
Component:
Profile: Migration
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mcafee, Assigned: Henry.Jia)

Details

(Keywords: fixedOEM)

Attachments

(1 file, 3 obsolete files)

patch with a line change
6.27 KB, patch
ccarlen
: review+
scc
: superreview+
Details | Diff | Splinter Review 
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".
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.
Target Milestone: M14
Assignee: sspitzer → dbragg
Status: ASSIGNED → NEW
Reassign to dbragg
Status: NEW → ASSIGNED
Oops, never marked "assigned".  Accepting.
Target Milestone: M14 → M15
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
Status: NEW → ASSIGNED
Whiteboard: [nsbeta3-]
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.
Keywords: nsbeta3
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.
Attached patch patch for review (obsolete) — — Splinter Review 
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
Keywords: patch
Can anyone take a look at this bug and review the patch? Thanks.
Keywords: review
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+
Attached patch new patch for review (obsolete) — — Splinter Review 
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
Can anyone take a look at this patch(attachment 79784 [details] [diff] [review])? 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
Attached patch patch with compact code (obsolete) — — Splinter Review 
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 racham@netscape.com to the CC list.
Let me take care of this bug, add racham@netscape.com 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: 22 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
Whiteboard: [nsbeta3-], branchOEM → [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.
Keywords: fixedOEM
Whiteboard: [nsbeta3-], branchOEM+, fixedOEM
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.
Thx for the catch.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: