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

VERIFIED FIXED

Status

defect
P3
normal
VERIFIED FIXED
20 years ago
3 years ago

People

(Reporter: mcafee, Assigned: Henry.Jia)

Tracking

({fixedOEM})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

Reporter

Description

20 years ago
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.

Updated

20 years ago
Target Milestone: M14

Updated

20 years ago
Assignee: sspitzer → dbragg
Status: ASSIGNED → NEW

Comment 2

20 years ago
Reassign to dbragg

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 3

20 years ago
Oops, never marked "assigned".  Accepting.

Updated

19 years ago
Target Milestone: M14 → M15

Comment 4

19 years ago
moving to M16
Target Milestone: M15 → M16
dbragg is on sabatical.  assigning to cathleen for re-delegation.
Assignee: dbragg → cathleen
Status: ASSIGNED → NEW

Comment 6

19 years ago
reassigning to doug.  :-)
Component: Profile Migration → Installer: XPInstall Engine
QA Contact: gbush → jimmylee

Comment 7

19 years ago
wrong mass change.
reassign to dbragg, and set target milestone to M17
Assignee: cathleen → dbragg
Target Milestone: M16 → M17

Updated

19 years ago
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

Comment 9

19 years ago
Grace: Isn't this more of a XPInstall: XPI Packages bug?

Comment 10

19 years ago
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 → ---

Comment 12

18 years ago
Reassigning profile migration bugs to the current owner
Assignee: dbragg → racham
Status: ASSIGNED → NEW

Comment 13

17 years ago
Except for preferences.js , other old version files should also be deleted, such
as   some old address book (*.dat). 
Assignee

Comment 14

17 years ago
Can this bug assigned to me? Let me try to solve it.
Assignee

Comment 15

17 years ago
Posted 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
Assignee

Updated

17 years ago
Keywords: patch
Assignee

Comment 16

17 years ago
Can anyone take a look at this bug and review the patch? Thanks.
Assignee

Updated

17 years ago
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+
Assignee

Comment 18

17 years ago
Posted 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
Assignee

Comment 19

17 years ago
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);
Assignee

Comment 21

17 years ago
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.
Assignee

Comment 23

17 years ago
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?
Assignee

Comment 24

17 years ago
Hi, Conrad Carlen, can you or anyone else review the patch 79784 for this bug 
again? Thanks.
Assignee

Comment 25

17 years ago
Can anyone take a look at the patch for this bug? :<
Thanks
Henry
Assignee

Comment 26

17 years ago
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.
Assignee

Comment 28

17 years ago
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
Assignee

Comment 29

17 years ago
Posted 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
Assignee

Comment 30

17 years ago
Let me take care of this bug, add racham@netscape.com to the CC list.
Assignee

Comment 31

17 years ago
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+
Assignee

Comment 33

17 years ago
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 35

17 years ago
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+
Assignee

Comment 36

17 years ago
Patch landed. Marking fixed.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 37

17 years ago
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?
Assignee

Comment 38

17 years ago
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.

Comment 40

17 years ago
verifying for Mozilla
Please open new bug in Bugscape if wanted for commercial builds
Status: RESOLVED → VERIFIED
Assignee

Comment 41

17 years ago
Apply for a= for branchOEM
Whiteboard: [nsbeta3-] → [nsbeta3-], branchOEM

Updated

17 years ago
Whiteboard: [nsbeta3-], branchOEM → [nsbeta3-], branchOEM+

Comment 42

17 years ago
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.
Assignee

Comment 43

17 years ago
Margaret,

This is not a critical bug. Should we put it in or hold for the next release?

Henry

Comment 44

17 years ago
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.

Comment 45

17 years ago
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.
Assignee

Updated

17 years ago
Whiteboard: [nsbeta3-], branchOEM+ → [nsbeta3-], branchOEM+, fixedOEM
Assignee

Comment 46

17 years ago
In OEM branch.

Margaret, if something wrong, let me know.

Comment 47

17 years ago
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.

Comment 48

17 years ago
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

Comment 49

17 years ago
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.

Updated

17 years ago
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.)
Assignee

Comment 51

16 years ago
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.
Assignee

Comment 54

16 years ago
Thx for the catch.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.