> > To do this, we'd have to drag this support all the way down to the > lowest level where we pass file names to the OS APIs. And then we'd > have to disallow root directories of one letter, like C:/c, which are > entirely legitimate. All that just to handle the few commands during > the build process that need it. I find this solution even more ugly > than the unmsys--file-name gork. I'm afraid I don't understand your point here. To reiterate, the current problem is that Emacs does not know how to treat "/C" in the beginning, therefore it assumes that the path given does not have a drive letter, so it add "c:" in front of the given path as a wild guess. The only thing that I propose to change in that logic is to allow paths which contain a slash + a single letter in the beginning, e.g. "/C", so that when Emacs sees it, it simply converts that to "C:" and passes further to old logic of path manipulation. In other words, nothing has to be changed to the lowest level as you say. My change involves one `if' statement or so in the very beginning of the path processing. Furthermore, I don't get it why you would have to disallow "C:/c"? If somebody passes "C:/c" then it's perfectly valid Windows path. If somebody passes "/C/c", then according my proposal it will be converted to "C:/c" and then processed further.