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

[Daniel Sutton]

(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