From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) Gecko/20020313 BuildID: 2002031312 If the file system fills up, appreg is left out of sync with the user profile in the .mozilla subdirectory. Reproducible: Always Steps to Reproduce: 1.Start mozilla with the user on full file system. 2.Exit 3.Restart mozilla Actual Results: Error message that the profile is not in the directory specified. Expected Results: If the profile and appreg can't both be updated, neither should be updated. The result is that the user loses their profile, which can represent a lot of work on their part and a lot of work to set up again.

how big is your appreg file?

> Actual Results: Error message that the profile is not in the directory specified. Was this a pre-existing profile or one you added in this session? The reason I ask is that, if the profile was ever added to the registry successfully at some point, I don't see how the registry could know that the profile exists but not where it exists. Unless you add a new profile, the only info in the registry that's updated in a session is the current profile used, not its location. I think what needs to be done is a "safe-save" technique when writing out the registry. That is, write it out to a temp file in the same dir and, only when that has succeeded, delete the actual registry and rename the temp file.

The appreg file was 3184 bytes when the problem occurred. Nothing is being done with profiles when the problem occurs. The file system probably filled up while mozilla was running. There appeared to be a profile in the .mozilla/user directory but .mozilla/user-1 was an empty directory. I think the last entry in appreg was /home/suser/.mozilla/user-1/a1cscs0v.slt. (I'm guessing from an od -s appreg).

similar problem may be bug 152054

This sounds similar to the problem I just reported Bug ID 158531. My system is Solaris 8 x86. I get a corrupt appreg file that shows it self as "directory containing the profile can not be found". Analysis showed the path to the profile is at the end of appreg and when corrupted is preceeded by 3 non-ascii characters -- 0xEF, 0xBB, and 0xBF. Also, the final character of the path, the "t" of ".slt" is overwritten by a null byte. Rewriting that part of the appreg file with a binary editor corrects the problem.

This bug may be a dup of bug 153562. Related: bug 109739 (about the needlessly growing appreg) See also meta bug 123929.

reporter: Does this problem exist in newer versions of mozilla??

No comment after 1 month, closing this bug as invalid. If this problem exists, please look firstly at other appreg bugs.