Re: some emacs-21.1.1 problems

[Dr. Mirko Luedde]

J.Rumney wrote: 
>>3. With mailcrypt-3.5.6, gnupg-1.0.6: when decrypting a buffer:
>>"start-process: Removing old name: no such file or directory,
>>d:/tmp/mailcrypt-gpg-stderr-764AJM".
>>
>>E.Karni wrote: 
>>> So the directory "d:\tmp" does exist on that system, yes?
>>
>>Yes, I have c:\tmp, d:\tmp, c:\Tools\cygwin\tmp. 
>
>So how do you know which of the above "/tmp" is refering to
>at any one point in time?

Cygwin interprets filepaths in a particular way (which seems to vary
sometimes among releases).  In order to specify a path to the
directory, say, "c:\Tools\cygwin\tmp", cygwin would offer at least the
following variants:

1. "c:/Tools/cygwin/tmp"
2. "/cygdrive/c/Tools/cygwin/tmp"
3. "/tmp"
4. in some prior version also "//c/Tools/cygwin/tmp" was possible,
   but this apparently collided with UNC names.

Cygwin by default mounts its installation directory, in my case
"c:\Tools\cygwin" to "/". So "/tmp" always refers to the "tmp"
directory under cygwin's install directory. "/usr/local" e.g. refers
to "c:\Tools\cygwin\usr\local", and so on. This makes "#!/bin/sh" work
in shell scripts.

>>Furthermore, 
>>
>># echo $TMP
>>/tmp
>># echo $TMPDIR
>>/tmp
>
>This is a dangerous way to set TMP and TMPDIR on Windows. Please 
>specify a drive
>letter.

See above. 

>>I also tried out several versions of mentioning tmp directories in
>>mailcrypt.el, e.g.
>>
>>(defvar mc-temp-directory "d:\\tmp"
>>  "*Default temp directory to be used by Mailcrypt.")
>
>You should use setq to set variables, not defvar.
>defvar is for defining variables, and will not override existing 
>values.

This is original "mailcrypt.el" code. I kept everything except for the
tmp directory name.

>>Neither did work. But the error message cited above ("start-process"
>>...) was always adapted to the new tmp path.
>
>Then there is a bug in mailcrypt. Perhaps it relies on TMP (or
>TMPDIR or TEMP) being the same as mc-temp-directory?

In order to check this I ensured that the variables "TMP", "TMPDIR",
"TEMP", "mc-temp-directory" and "temporary-file-directory" did have
the same values. Unfortunately, I could not use "c:/tmp", since cygwin
does translate this value into "/cygdrive/c/tmp". So I chose this
latter value also for the ELisp variables.  What I got is:
"start-process: Removing old name: no such file or directory,
d:/cygdrive/c/tmp/mailcrypt-gpg-stderr-680Ok5".  So mailcrypt or emacs
was prepending a drive letter to the pathname, invalidating it.

>>> From the error message, it sounds like the problem happens in the
>>> delete-file primitive, but I cannot figure out how is start-process
>>> related to that.
>
>I think mailcrypt creates a temporary file, then deletes it
>when finished. Maybe the temporary file is created by gpg/pgp,
>so both need to be looking at the same temporary directory.

I agree with your analysis. One tool creates the file, another one
wants to delete it, but doesn't find it. Some of the processes that
are spawned in the background do understand Unix-like file names,
others, as well as the ELisp code, don't. Maybe, if the "d:" was not
prepended (see above), everything would work fine.

>(From backtrace)
>
>(shell-file-name "/bin/sh")
>
>This is probably the same version of bash that you are having
>problems with. Is it possible that this version of bash is
>responsible for ALL these problems? Could you try setting
>any environment or elisp variables that point to bash or /bin/sh
>back to %emacs_dir%\bin\cmdproxy.exe.

I set everything back to cmdproxy (no "bash" or "/bin/sh" or similar
occuring in any environment variable anymore) and set the variables
"TMP", "TEMP", "TMPDIR", "mc-temp-directory" and
"temporary-file-directory" to "c:/tmp" (I tried forward and also
backward slashes, correctly doubling the latter inside ELisp
code). The error is: "start-process: Removing old name: no such file
or directory, c:/tmp/mailcrypt-gpg-stderr-6802y5".  Here only emacs,
mailcrypt and gpg where involved.

Meanwhile I found that I cannot use dired for other drives than "d:"
(where I start emacs) anymore. When I specify "c:/", I get
`original-insert-directory: Reading directory: "ls -lona -- c:/"
exited with status 1'. When I specify "/cygdrive/c/", I get
"dired-readin-insert: Directory d:/cygdrive/c inaccessible or
nonexistent". 

There seem to be some major incompatibilities in specifying filepaths.
I would like to compile emacs under cygwin in order to get rid of
these pathname problems (Xemacs/cygwin does work rather smoothly), but
didn't succeed so far.

Regards, Mirko.