GNU bug report logs - #31981
26.1; flymake: removes temporary file before finishing check

Previous Next

Full log

Message #14 received at 31981 <at> debbugs.gnu.org (full text, mbox):

From: Joel Rosdahl <joel <at> rosdahl.net>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31981 <at> debbugs.gnu.org
Subject: Re: bug#31981: Fix 'flymake-proc-legacy-flymake' temporary file
 deletion bug
Date: Wed, 28 Aug 2019 21:18:33 +0200

[Message part 1 (text/plain, inline)]

On Wed, 28 Aug 2019 at 01:38, Noam Postavsky <npostavs <at> gmail.com> wrote:
> If I'm reading flymake-proc-init-create-temp-buffer-copy correctly, it
> actually makes a new temporary file (say T1), but the file name is stored in
> a single variable, so Emacs effectively forgets about the original file T.

The create-temp-f parameter to flymake-proc-init-create-temp-buffer-copy is in
practice flymake-proc-create-temp-inplace, which always creates the same result
for a given file-name and prefix. And file-name and prefix are the same for
both modification A and B (since it's the same file). Or am I missing
something?

> So here it deletes T1, leaving the original T. And then B will fail, since it
> needs T1, not T.

Nope, it's T both times, but it's true that only generating a unique filename
wouldn't fix the issue since, as you said, the filename is stored in a single
variable.

> Would it work to store the filename in the process object instead, with
> process-put (and then the sentinel can retreive it with process-get)?

Yes, flymake-proc-create-temp-inplace could create a unique filename and store
it in the process, but that wouldn't help since the cleanup function doesn't
have access to the process (since the process is stored in a single variable as
well). Passing the process or filename(s) to the cleanup function would work,
but it would break the interface to existing custom cleanup functions which
don't take a parameter, so I wrote off that solution earlier.

...unless we can pass the value(s) using dynamic binding to the cleanup
function. I didn't consider this before since lexical binding would prevent
such a solution, but I just learnt to my surprise that global defvar-ed
variables are still dynamically scoped.

Attached is a new proposed solution as sketched above.

-- Joel

[0001-Fix-flymake-proc-temporary-file-deletion-bug.patch (text/x-patch, attachment)]

Previous Next

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