7921 - DOGFOOD - Saved bookmarks disappear when migrating from build to build

Status: VERIFIED FIXED

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

Description

[Suresh Duddi (gone)]

Is this ours or does this go to dons group ?

Comment 1

[Chris Waterson]

This is ours. Is profile information persistent yet? Or is it just stored in
the "dist" directory. If we store it in the "dist" directory, yeah, it'll get
clobbered for each build.

Comment 2

[selmer (gone)]

Bhuvan, please help make sure they're calling the right interface to get the
profile directory and that they're getting the right value.  If the problem is
that dist is getting blown away, that'll have to wait until we deal with the
single-user vs multi-user stuff in M8 or M9.

Comment 3

[racham]

At present the default location for the profile directories is dist\Users50.
However user can opt to store the information in a different directory (provide
the directory name at the profile creation stage, say c:\profile1) to avoid
losing information on  clobber. The problem with work around is, if you delete
mozregistry.dat, the profile information is gone (though the directories are
intact, if they are stored in a location other than the default i.e.,
dist\Users50). If deleting mozregistry is a must thing to do, then while
creating a new profile use the old profile dir (e.g., c:\profile1) as the
location of that profile in order to point to the data we gathered before the
migration.

The ideal solution will be to come with a policy to have a default directory
for profiles in a location other than dist\Users50.

Steve/John,

Any ideas on a preferred location for profile dirs ?

Comment 4

[selmer (gone)]

Actually, yes, I have a plan for profile directories.  On multi-user systems, we
should put our mozregistry.dat file in the OS user's directory like we do on
Un*x.  On single-user systems, I'm proposing that we fake up a user directory
(assuming I can figure out who you logged in as) and pretend it's a multi-user
system.  By hiding the single-user cruft in the nsFileLocation stuff, profile
manager can get nice XP behavior without a lot of effort.

The resulting model is a hierarchy of user then profile.  This means that each
user can have multiple profiles and that they're separate from any other users
profiles.  (Yeah, I know I said we weren't likely to do this work, but it solves
a lot of problems.)

If anyone knows how to find the OS user info on Windows95/98 and anything at all
about how to do this on Mac, please let me know :-)

Comment 5

[Chris Waterson]

I'll update the bookmarks code to use the profile directory.

Comment 6

[Chris Waterson]

Later to M8 because this depends on 8019 being fixed.

Comment 7

[Chris Waterson]

Look in profile directory _first_ before failing over to the "default"
bookmarks.

Comment 8

[Grace Bush]

What file should be holding saved bookmarks?  My bookmarks are being saved from
build to build despite my emoving profile information but I cannot verify a file
that is saving them.

Comment 9

[Grace Bush]

Linux:
ftp://sweetlou/products/client/seamonkey/linux_glibc/2.0/x86/1999-07-08-18-M8

Mac:
ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-07-08-18-M8

Windows:
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-07-08-19-M8

Comment 10

[selmer (gone)]

Since we'd like the file to have the same basename on all platforms and we'd
also like people to be able to just copy the old file over, we've decided that
looking for the new standard name first and then looking for the old name makes
the most sense.  This allows migration, standard naming, and some common local
usage to all work properly.  The only wierdness is when you have both files
since the one with the old name would be ignored in that case.

Any problems with that?