Eli Zaretskii writes: Hi Eli, >> >> >> The only difference I could think of is that the directory Emacs uses >> >> >> here has whitespace in its name (see my original report), whereas on >> >> >> Windows 10 it probably doesn't. >> >> > >> >> > FTR, if I use a directory with spaces in its name, it fails for me as >> >> > well. I'm now debugging ... >> >> >> >> It looks, like it is a problem in the test case code >> >> itself. abbreviate-file-name does not work as I expect in this >> >> combination. >> > >> > Can you tell more about this? I'm surprised any file-related >> > primitive in Emacs cares about whitespace in file names. >> >> Perhaps we have uncovered a bug in abbreviate-file-name, don't >> know. I'll check when time permits. > > I'd like to understand this sooner rather than latter. Can you show > some simple recipe which fails under these conditions? I haven't completed all tests yet, still in debugging. As recent result, I believe abbreviate-file-name works correctly. Rather, the problem seems to be with temporary-file-directory. It is used in the prelude of the test to set the HOME environment variable. But later on, in the macros files-tests--with-temp-non-special and files-tests--with-temp-non-special-and-file-name-handler, it is modified to (file-truename temporary-file-directory) - this difference seems to be the culprit. >> However, it isn't related to the change in question of this bug report, >> handling expand-file-name for constructs like "/:~..." and >> "/ssh:host:/:~...". abbreviate-file-name has been used to create a >> temporary test file for this case, it isn't target of the test itself. > > I applied your changes to the test, and it passes after that, thanks. Could you pls apply the appended patch instead? I'll continue to finish all my tests, but if this patch passes also in your environment, it would give me sufficient confidence that it is fixed. Best regards, Michael.