95331 - Loss of User Profile and all data in the Profile

Status: RESOLVED FIXED

(Core Graveyard :: Profile: Migration, defect)

Description

[Matthew Kruer]

Summary

Loss of User Profile and all data in the Profile

Description

Recreating a profile from fresh install and restoring a backed up copy of the
user profile results in loss of all data; invokes fresh start even if the backup
profile is legitimate.

Steps to Reproduce

--Warning. I highly recommend doing this on a test system that you do not need
to keep any information one. I can not be responsible for the loss of your data.--

1. Install Mozilla 9.x and create or import a profile.
2. Change settings and or enter information
3. Close Mozilla
4. Copy all your user information stored in your profile (Usually stored in
C:\WINDOWS\Application Data\Mozilla\Profiles directory in Windows 9x) This is
your backup.
5. Rebuild your system or Launch the Profile manager and delete the current profile
6. Recreate the Profile and close down the browser.
7. Copy back all your information from your backup back into the new Profile you
have just recreated. (The current way Profiles are generated Concern me right
now because every time you make a new profile it creates a subdirectory that is
randomly generated *.slt and all the information is placed in there.)
Ex. C:\WINDOWS\Application Data\Mozilla\Profiles\User\rpgixsfq.slt
Ex. C:\WINDOWS\Application Data\Mozilla\Profiles\User\w98uwr0f.slt
8. If you re-launch Mozilla again and you have not copied the information that?s
was in the original *.slt to the new *.slt, Mozilla will launch as a new
account. If you do copy the information into the new randomly generated *.slt
directory. I have noticed two results. 
8.1 Result all the information will be lost and is unrecoverable.
8.2 Mozilla launches but is missing all other components Ex. Navigator bar, side
menu, etc? basically it is just an open window and only the home page can be
loaded. You can not bring up any other functions of Mozilla

Actual Results

Congratulations you just loss all your data permanently.

Expected Results

Jumping back to Netscape 4.x users could copy their user data directory as a
backup. In the event of a system crash that required the rebuilding of the
machine, the user could simply create the profile again, and once the profile
was created, they just copy back the backup copy of all the information in the
profile. The next time the user launched Netscape all the users original setting
would be there.

Ideally I would like to just copy a profile into the Profiles Directory and not
have to worry about anything. The Profile manager would automatically detect and
verify the any and all profiles in the Profile directory even if it was not
generated using the Profile manager on that machine. This would allow a person
to take the profile with them and not limit then to that machine. I would also
recommend removing the randomly generated subdirectory *.slt and just place all
the information into the root of that user profile. I think its unnecessary and
utterly confusing.

Additional Information

I have preformed this "trick" in Netscape 4.x since it came out with no
problems. In NS6/Mozilla I have had this problem since Mozilla 0.6.x and it has
yet to be resolved. This should be moved to the front of the list on things to
do due to its potential for wide spread impact. 

I would move over to Mozilla as my default for e-mail if this issue were
resolved. But because of the reasons listed above I have yet to migrate and will
not if I can not even recover from a backup of the profile.

Comment 1

[Grace Bush]

Matthew,

See bug 56002 for discussion of why .slt directory is created for a profile.

Using your steps I was able to retain my data.  
What must be done:
copy contents of first profile.slt directory into second profile.slt directory.  
The registry will show that the second profile created will have its data in (in 
my case 04pptnxo.slt- I had to copy contents of 99932eth.slt into that 
directory. Mozilla launched and I had access to that profile data- Mozilla will 
look for the 04 directory.

Cumbersome? you bet. alas, the behavior of 4.x where you can accomplish this 
does not exist in Mozilla.  However, there is a bug that requests the feature of 
backing up profiles which will prevent data loss.
You may want to log another bug to request a feature you would like to see.

I will mark this as works for me- no data loss- please confirm

Comment 2

[Matthew Kruer]

I am unable to confirm. I am still having trouble with restoring profiles. I get
all the information for stuff such as bookmarks, passwords and what not, but as
for the mail. That is still missing. I try to retarget the directory but it ends
up wiping out all the information. There is one last way I need to try and it
might be how you did it and don't have the problem. Basically re-linking the
directory to the mail on the restore profile and then restore the mail

I did resolve one issue with Mozilla launches but is missing all other
components Ex. Navigator 
bar, side menu, etc. and I will post it as a new bug as soon as I have the time.

I have also write a new bug/enhancement that could eliminate this problem all
together located at http://bugzilla.mozilla.org/show_bug.cgi?id=96606 . Please
check it out. and submit your comments.

Matt

Comment 3

[Matthias Versen [:Matti]]

Reporter: Please don't touch the Target Milestone and Priority fields (they are
for the developers). 

Comment 4

[[e-mail]]

These are the steps to restore a backed up profile:
1. Restore the profile's files into the original .slt directory.
2. Reinstall mozilla.
3. Start mozilla -profileManager
4. If mozilla has already created a default profile, you might need to delete it.
5. Ask it to create a profile in the .slt directory.
Mozilla will then attach your backed up profile into the profile list.

Comment 5

[Keyser Sose]

Marking NEW so someone more knowledgeable can look at this.

Comment 6

[Conrad Carlen (not reading bugmail)]

> I get all the information for stuff such as bookmarks, passwords and what not,
> but as for the mail. That is still missing.

The reason for this is that pref.js (where your mail settings are stored)
contain full paths to the files, which include the name of the old .slt dir.
Since the new one is different, all of these paths used by mail are now invalid.

If the paths within a profile dir were relative instead of absolute, we would
not have this problem. Also, with relative paths it would be easy to (1) move
profiles, and (2) restore a backed up profile.

The bugs for relative paths - bug 12911 and 76245.

Comment 7

[racham]

Conrad, do you remember if there is bug where we want to allow users to point a
particular profile folder ? thanks.

Grace, could you reproduce the dataloss part of this bug..? thanks.

Comment 8

[Conrad Carlen (not reading bugmail)]

> do you remember if there is bug where we want to allow users to point a
> particular profile folder ?

Sort of. See bug 77295. If we had an "import" or "restore" button, you could
take some profile which you had backed up and re-add it as-is to the profile
list. I think this would be a good feature. It's easy to do - probably the
hardest thing is deciding what to call the button ;-)

Comment 9

[Grace Bush]

I was able to recreate a profile without data loss.  It is a tricky process and 
easy to make a misstep and  lose data however.

Comment 10

[Bruce Robson]

I have a dual boot system with windows 95 on C: (a FAT partition)
and WinNT on E: (a NTFS partition). I was able to install communicator
4 under both operating systems and make the NT instalation use the
profile created by the Win95 installation on the C: drive.

I haven't managed to do this with Mozilla. Is it possible ?

If not the fixes for this bug should also allow this.

Comment 11

[Matthew Kruer]

This will most likely be solved when the un-salt the directories, or allow for
unsalted user profiles. But that does not look like it going to happen till
mozilla 1.0.1, which is stupid because it going to screw alot of poeple if or
when AOL decides to move to mozilla when it hits 1.0. The patch is there but
they dont want to implment it. thats my flamebait

Comment 12

[Mike]

This has been driving me nuts as well.
I found this info on the web, and it might be the key to solving the problem, if
someone could write a script to do this automatically, like a "Lock/Unlock"
Preferences" button on the "Set Preferences" menu.
Here's what I found:


"Mozilla stores most of a user's preference settings in the prefs.js file. 
Because so many of the settings are retained in this file, your ability to
modify and secure this file can greatly assist you in securing Mozilla against
unwanted changes and uses.

The prefs.js file is stored in a subdirectory of the main Users directory,
Users50.  Mozilla installs this Users50 directory in different locations
depending on whether you have Netscape already installed and the operating
system that you are using.  On my WindowsNT machine with Netscape, it was
installed in: C:\Program Files\Netscape\Users50\.  On my Windows2000 machine
without Netscape, it was installed in C:\Documents and Settings\User Account
Name\Application Data\Mozilla\.  

There are a couple of key points to know about the prefs.js file.

1.  It is generally safe to modify this file, so long as you know what you are
doing!  You will only run into problems if you make indiscriminate changes to
the file.  Even if you delete the file, Mozilla will recreate the file the next
time it is started.

2.  Any changes made to the preferences during a Mozilla session are saved to
the prefs.js file when Mozilla is closed.  If you have modified the prefs.js
file, Mozilla may overwrite those changes when it closes!  
You can prevent changes to your modifications or to the general preferences in
Mozilla by setting the properties for the prefs.js file to read-only.  When
Mozilla closes, it will discard any changes made instead of writing those
changes to prefs.js.  This setting will NOT prevent patrons from making changes
to the preferences during a session, such as changing the browser home page. 
However, any of their changes are not permanent.  You can restore Mozilla back
to your configuration by simply closing the browser and starting it back up again.  

You also can use "edit" the prefs.js file to directly change preferences set
through the browser interface and some other settings that can not be accessed
through the interface."


Thanks to whoever wrote this... hope it helps.
Keep The Faith, Mike.

Comment 13

[Mike]

PS: "Setting prefs.js to "Read Only":
1.  Browse to the Users  directory in the appropriate location for your
operating system and locate prefs.js.

2.  Right-click on prefs.js and select Properties.  

3.  Check the Read-only box. If you need to make any changes in the future,
remember to uncheck this setting before changing the preferences or your changes
will not be saved.

Regards, Mike.

Comment 14

[Mike]

*** Bug 155017 has been marked as a duplicate of this bug. ***

Comment 15

[Mike]

*** Bug 155019 has been marked as a duplicate of this bug. ***

Comment 16

[Matthew Kruer]

I would like to add “data migration” and “profile restore” to the keywords. I
believe the issue with losing all the information has been resolved, via various
work arounds, but the other part of the bug still has not yet been resolved,
easy way to restore a profile

Comment 17

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 18

[Vedran Miletic]

retargeting

Comment 19

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 20

[Matthew Kruer]

I think this bug can be closed. The later versions of the main branch do not appear to have this issue anymore, simply coping the data from within the original salted directory to a new systems generated salted directory allows users to migrate their data without loss. The old salting variable is automatically updated in the , and there is no reason to play the salt renaming game within the config files.

Comment 21

[David Edwards]

This has just happened to me! I was using 2.0.11, Ubuntu 10.04 x86_64 version, and selected the 'Check for Updates' option. The working bar flashed at me for some minutes, no obvious progress, so I pressed Cancel. Ah, I thought, perhaps I need to be root. I fired up Seamonkey from a root window, and checked for updates once more. Again, no progress, so I press Cancel.

The status bar suggested that I had mail waiting. 'Where is it going to write that?', thinks I. So I close it. I now start up Seamonkey as normal, and my email accounts have disappeared.