bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61668: Bug in flymake-proc with fix


From: João Távora
Subject: bug#61668: Bug in flymake-proc with fix
Date: Tue, 21 Feb 2023 12:42:15 +0000

Hi Camden,

Flymake-proc is a deprecated part of Flymake.  I haven't used or tested
it in a long time (there were never automated tests for it).  When I
redesigned Flymake years ago, in which flymake-proc became another
backend, I tested some basic use cases, but I didn't change the
underlying code, including the directory calculating parts and helpers.

In other words, this is not "my code" and I never understood it.

So if you think the change makes sense, go for it i.e. provide a patch
that we can push. I think there are very few users of this backend
anyway.

João

On Tue, Feb 21, 2023 at 12:35 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Adding João.
>
> > Date: Mon, 20 Feb 2023 11:23:02 -0700
> > From:  Camden Narzt via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >
> > I’m sorry if this is not the correct place to report a flymake-proc bug, 
> > but since flymake is included in the emacs git repo I figured it might be 
> > ok.
> >
> > I’m currently seeing incorrect behaviour from the 
> > `flymake-proc--delete-temp-directory` function. The path is parsed and then 
> > reassembled incorrectly as the following backtrace extract demonstrates:
> >
> > flymake-proc--safe-delete-directory("/private/var/folders/p7/03_g5t611499lmjqhwc5tljr0000gn/T/000gn/T/Users/camdennarzt/Developer/Java/getargv.java/src/main/java/cam/narzt/getargv")
> > flymake-proc--delete-temp-directory("/private/var/folders/p7/03_g5t611499lmjqhwc5tljr0000gn/T/Users/camdennarzt/Developer/Java/getargv.java/src/main/java/cam/narzt/getargv/“)
> >
> > As you can see the `000gn/T/` segment of the path gets duplicated when 
> > `flymake-proc--safe-delete-directory` gets called.
> >
> > This is because in `flymake-proc--delete-temp-directory` when the `suffix` 
> > variable is declared it is assumed that `(directory-file-name 
> > temporary-file-directory)` is a prefix of the `dir-name` argument, however 
> > `(directory-file-name temporary-file-directory)` doesn’t seem to resolve 
> > symlinks in the path whereas `dir-name` seems to have symlinks already 
> > resolved, so they don’t necessarily match. On my system the difference is:
> >
> > (directory-file-name temporary-file-directory) → 
> > "/var/folders/p7/03_g5t611499lmjqhwc5tljr0000gn/T”
> > dir-name → 
> > "/private/var/folders/p7/03_g5t611499lmjqhwc5tljr0000gn/T/Users/camdennarzt/Developer/Java/getargv.java/src/main/java/cam/narzt/getargv/“
> >
> > Note the "/private” prefix on the `dir-name` path. That difference in 
> > length causes the suffix to be incorrectly determined and then causes a 
> > bunch of errors while any subsequent function call tries to work with a 
> > path with the `000gn/T/` segment duplicated which obviously doesn’t exist 
> > in the fs.
> >
> > Changing the suffix variable to be computed as follows fixes the bug:
> >
> > (substring dir-name (1+ (length (file-truename (expand-file-name 
> > (directory-file-name temp-dir))))))
> >
> >
> > If this can be fixed that’s great, if there’s somewhere else I should 
> > report this I’d love to know.
> >
> > Cheers,
> >
> > Camden Narzt
> >
> >
> >



-- 
João Távora





reply via email to

[Prev in Thread] Current Thread [Next in Thread]