bug#13921: 24.2; Misbehavior of expand-file-name on Cygwin with Emacs 24.2

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 10 Mar 2013 22:03:31 -0400
> From: Barry OReilly <gundaetiapo@gmail.com>
> 
> When I attempted to build CEDET from their bzr trunk (revno 8498), the
> build failed due to expand-file-name function returning an incorrect "d:"
> prefix.  Under other conditions expand-file-name returns the correct "c:"
> prefix.  Some command line IO will illustrate:
> 
> [CEDET build issues this:]
>  emacs -batch --no-site-file --eval '(setq debug-on-error t)' -l
> "../../cedet-remove-builtin.el" -L . --eval '(progn (require (quote
> cedet-compat)) (require (quote mode-local)))' -L ../eieio/ -L ./ -L ./
> --eval '(progn  (setq generated-autoload-file
> "/home/epich/sw/cedet/lisp/cedet/loaddefs.el"))' -f batch-update-autoloads
> /home/epich/sw/cedet/lisp/cedet
> Debugger entered--Lisp error: (file-error "Opening output file" "no such
> file or directory" "d:/home/epich/sw/cedet/lisp/cedet/loaddefs.el")
>   write-region(";;; loaddefs.el --- automatically extracted
> autoloads\n;;\n;;; Code:\n\n\f\n(provide 'loaddefs)\n;; Local
> Variables:\n;; version-control: never\n;; no-byte-compile: t\n;;
> no-update-autoloads: t\n;; coding: utf-8\n;; End:\n;;; loaddefs.el ends
> here\n" nil "d:/home/epich/sw/cedet/lisp/cedet/loaddefs.el")
> 
> autoload-ensure-default-file("d:/home/epich/sw/cedet/lisp/cedet/loaddefs.el")
>   autoload-find-generated-file()
>   update-directory-autoloads("/home/epich/sw/cedet/lisp/cedet")
>   apply(update-directory-autoloads "/home/epich/sw/cedet/lisp/cedet")
>   batch-update-autoloads()
>   command-line-1(("--eval" "(setq debug-on-error t)" "-l"
> "../../cedet-remove-builtin.el" "-L" "." "--eval" "(progn (require (quote
> cedet-compat)) (require (quote mode-local)))" "-L" "../eieio/" "-L" "./"
> "-L" "./" "--eval" "(progn  (setq generated-autoload-file
> \"/home/epich/sw/cedet/lisp/cedet/loaddefs.el\"))" "-f"
> "batch-update-autoloads" "/home/epich/sw/cedet/lisp/cedet"))
>   command-line()
>   normal-top-level()
> 
> Comparing the backtrace above with the source code, it's evident
> expand-file-name prepended the "d:" to the filename to get:
> "d:/home/epich/sw/cedet/lisp/cedet/loaddefs.el".
> 
> However, when I evaluate (expand-file-name
> "/home/epich/sw/cedet/lisp/cedet") in the the scratch, I get
> "c:/home/epich/sw/cedet/lisp/cedet".

This is not a bug in Emacs.  You are invoking a native Windows build
of Emacs from the Cygwin shell, which passes to Emacs Posix-style
absolute file names like /home/epich/sw/cedet/lisp/cedet.  But the
native Windows build of Emacs does not understand the Cygwin mounts,
so it cannot resolve such file names correctly.  What it does is
simply prepend the current drive's letter to the file name.

So when you expand-file-name in *scratch*, it takes the drive letter
of the default-directory defined in *scratch*, which is C:, because of
this:

> epich@laptop02 ~/sw/cedet/lisp/cedet $ ls -l `which emacs`
> lrwxrwxrwx 1 epich None 51 Nov  5 22:02 /home/epich/bin/emacs -> /cygdrive/c/Users/epich/sw/emacs-24.2/bin/emacs.exe

This tells me that Emacs comes up in a directory on drive C:, and thus
its default-directory in *scratch will be something on C:.

By contrast, compilation of CEDET was probably run somewhere on drive
D:, so /home/epich/sw/cedet/lisp/cedet/loaddefs.el got D: prepended to
it.

I don't know why you invoke Emacs from the Cygwin Bash.  I suggest not
to, or to switch to a Cygwin build of Emacs.  Mixing these two
environments is asking for trouble.

IOW, this is pilot error, not a bug.