bug#36502: Fwd: bug#36502: 27.0.50; infinite loop in file-name-case-insensitive-p

[Daniel Sutton <dan@dpsutton.com>]

[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]

(repeated email as I omitted the bug email address)

Ken I believe I've figured it out and there was an important bit I left out.

The test in CIDER was ensuring a buffer was named correctly based on the
current project, and it set the current project's directory by setq'ing
default-directory. This seems to be a big no-no as the default directory
expects a well formed path. The doc string of default-directory being:

Name of default directory of current buffer.
It should be an absolute directory name; on GNU and Unix systems,
these names start with `/' or `~' and end with `/'.
To interactively change the default directory, use command `cd'.

So the "bug" can be reproduced by the following, which was the important
bits of the test:

(let ((default-directory "made/up/project/location"))
  (file-name-case-insensitive-p default-directory))

* note this will freeze your emacs

I believe your change caused the behavior here but it seems like a
reasonable change and CIDER is definitely not honoring the assumptions in
`default-directory`. We had some careless usages of this variable in our
tests and it seems like it has finally caught up to us. Unless you consider
this an edge case to watch for (and I can't imagine you do) it seems like
this should be closed.

Sorry for the noise and thanks for your help
Dan Sutton

On Thu, Jul 4, 2019 at 9:36 PM Daniel Sutton <dan@dpsutton.com> wrote:

> First thanks so much for your quick attention, Ken. I really appreciate
> it. I threw in some printlning and seeing the following output:
>
> originally: path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/
>
> filename from c:
> path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA
>
> filename from c:
> path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA
>
> filename from c:
> path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA
>
> filename from c:
> path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA
>
> filename from c:
> path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA/path/to/dirA
>
> from the following:
>
> if (NILP (Ffile_exists_p (filename)))
>   {
>     filename = Ffile_name_directory (filename);
>     while (NILP (Ffile_exists_p (filename)))
>       {
>         Lisp_Object newname = expand_and_dir_to_file (filename);
>         /* Avoid infinite loop if the root is reported as non-existing
>            (impossible?).  */
>         if (!NILP (Fstring_equal (newname, filename)))
>           break;
>         filename = newname;
>         message_with_string("filename from c: %s\n", filename, 1);
>       }
>   }
>
> So it seems to be growing the wrong way. I suppose this is the problem
> actually in expand_and_dir_to_file but i can't imagine why.
>
> On Thu, Jul 4, 2019 at 8:32 PM Ken Brown <kbrown@cornell.edu> wrote:
>
>> Please keep the bug address in the Cc.
>>
>> On 7/4/2019 3:35 PM, Daniel Sutton wrote:
>> > Locally when running `(expand-file-name "path/to/dirA/" nil)` it
>> expands
>> > to "/home/dan/projects/dev/cider/test/path/to/dirA/"
>> >
>> > when running under cask it expands to "/path/to/dirA/"
>>
>> So moving up the file system tree should eventually lead you to "/".  I
>> don't
>> see why you're getting an infinite loop.
>>
>> Ken
>>
>

[-- Attachment #2: Type: text/html, Size: 4751 bytes --]