GNOME Bugzilla – Bug 148305
no desktop at all if ~/.metacity folder corrupted/missing while ~/.gnome2/sessions references it
Last modified: 2007-04-09 21:05:18 UTC
quit X mv ~/.metacity ~/.metacity.old startx CONTROL-ALT-BACKSPACE (desktop fails to load) workaround: quit X mv ~/.gnome2/sessions ~/.gnome2/sessions.old startx
Should probably not exit if the session file on the command line is missing. I'd still like a fatal error if the session file is present but broken, since we need that to catch bugs, and it should not ever happen (except due to bugs)
Corrupded files should not cause Metacity to fail to start, should they? A few years ago, I lost a sector out from under a gnome-session file (a few hundred bytes of random garbage appeared right in the middle of it). Took me forever to figure out why I suddenly couldn't log in. Would it be hard to move the bad file out of the way, then put up a startup error? Something like, "The file ~/.metacity/session.state was corrupted. A new one was generated. Find the old one in ~/.metacity/session.state.bad"?
I can't reproduce this with HEAD. If a session file contains garbage, it causes the error Window manager warning: Failed to parse saved session file: Error on line 1 char 1: Document must begin with an element (e.g. <book>) but metacity loads anyway, as if the file hadn't been specified on the command line. Reporter: Can you still reproduce this error, or should I close this WORKSFORME?
I believe this is the same as bug 407981, which has been recently fixed. Since there was no answer to Thomas' last question, though, I'll just go ahead and mark it as a duplicate instead of asking for confirmation. :) *** This bug has been marked as a duplicate of 407981 ***