Subject: Re: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

From: Daniel Colascione <[email-masked]>
Date: Tue, 20 Nov 2012 09:36:36 -0800

On 11/20/12 9:03 AM, Eli Zaretskii wrote:
>> Date: Mon, 19 Nov 2012 21:02:22 -0800
>> From: Daniel Colascione <[email-masked]>
>> CC: Eli Zaretskii <[email-masked]>, [email-masked]
>>
>> 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.