Closed Bug 142247 Opened 22 years ago Closed 21 years ago

appreg update fails with full file system

Categories

(Core Graveyard :: Profile: BackEnd, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: alko, Assigned: ccarlen)

Details

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.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.