GNU bug report logs - #12911
24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt' files are written

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 12911 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#12911: 24.3.50; let users decide where (& perhaps whether) `emacs_backtrace.txt'	files are written
Date: Tue, 20 Nov 2012 19:03:27 +0200

> Date: Mon, 19 Nov 2012 21:02:22 -0800
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: Eli Zaretskii <eliz <at> gnu.org>, 12911 <at> 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%.

Maybe you guys think I've decided to put the file in the current
directory without any thought, just because I find it easier not to
futz with leading directories.  That's far from being true.  I did
invest some thought and a bit of research before making a decision.

Look, we are talking about emergency measures.  Not some normal
feature that writes files as a matter of habit.  Emacs is going down
in flames, and we want at the last moment to get some information from
it.  Code that does that must be as simple and as reliable as
possible, or it will not work, or, worse, cause nested exceptions that
will completely obscure the original cause.

%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.

(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.)

Accessing environment variables is another problematic place.  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?

And what if the %LOCALAPPDATA% doesn't exist as an environment
variable?  We'd need to access the Registry.  More complications and
API calls.

Someone else suggested to write into the directory where the Emacs
binary is installed.  But latest Windows versions make the directory
where programs are installed write-protected, especially if the user
has Administrator privileges.  Worse, there's this thing called
"filesystem virtualization", whereby the program is allowed to write
to those directories, but the data is actually redirected into some
hidden directory no one can find, even if they know about this.

Etc., etc.  Yes, the current directory is far from ideal.  But on
balance, I find it the lesser evil, and my long experience on
MS-Windows tells me that it is still the best choice for data you must
reliably write somewhere.

(Of course, Stefan says that he doesn't care if the data is lost, so
all of the above doesn't matter to him.  But, as long as we have this
feature, I _do_ care, otherwise I wouldn't have sit down and written
it.  Arguments whose authors don't care cannot possibly convince me.
If we _really_ don't care, let's go ahead and rip out the whole
feature.  That'd be at least honest.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.