On 11/20/12 9:03 AM, Eli Zaretskii wrote: >> Date: Mon, 19 Nov 2012 21:02:22 -0800 >> From: Daniel Colascione >> CC: Eli Zaretskii , 12911@debbugs.gnu.org >> >> On 11/19/2012 8:59 PM, Stefan Monnier wrote: >>>>> Because currently w32 users get annoyed with new files appearing where >>>>> they don't want any. >>>> Only one user complained so far. >>> >>> FWIW, I'd be annoyed if I were a w32 user and had to deal with >>> emacs_backtrace.txt files appearing in directories without my saying >>> so explicitly. >> >> I agree that the behavior is bad. If we really need these emacs_backtrace.txt, >> they should go under %LOCALAPPDATA%. > > %LOCALAPPDATA%? It doesn't exist on XP and earlier systems. There's > only %APPDATA% there. To distinguish, we'd need to probe the OS > version, or try both places. That means more system API calls. Not > rocket science, but still: complications, at the time that every tweak > counts. > Accessing environment variables is another problematic place. > And what if the %LOCALAPPDATA% doesn't exist as an environment > variable? We'd need to access the Registry. Compute the name of the backtrace file when Emacs starts. A crash is unlikely to corrupt a single allocation. > (Incidentally, %APPDATA% is what we by default treat as HOME, a > directory that I'm told is full of lasagna recipes we are not allowed > to contaminate.) %USERPROFILE% is where I put my lasagna recipes. %APPDATA% is full of non-user-visible application data on my system. Is %APPDATA% actually a user-visible directory of some sort on XP? > We are > crashing, so the heap or the whole arena can be trashed. Who can be > sure the environment variables will not point to garbled places? A process cannot reliably report all of its own crashes. That's why Windows Error Reporting monitors processes with a service and collects dumps of crashing processes from outside, in a separate process. Collecting information about most crashes is adequate.