Hi, 

The folder C:\Users\SVCBUI~1\AppData\Local\Temp exists and can be written.
The problem was that I ran a file cleanup in windows to free some space and this has deleted the temp file which the job does not find anymore.

Therefore I wanted to know if I can somehow force the plugin to regenerate those temp files if they do not exist

Are you certain that the user running the Jenkins process on the master computer can write to that temporary directory? The message is an indication that the user can't write to the directory or can't read from the directory.

Those temporary files are only used for the duration of a single command line git call which is run by the git client plugin and the git plugin. After each call, they are deleted.

The plugins give their best effort to remove those temporary files when they are no longer needed. There should be no need to regenerate temp files if they do not exist. Can you explain why you believe that you need to regenerate those temporary files?

I tracked down the source of this bug. It seems to affect newer git versions, from around version 2.19.2.

The problem is, that if git doesn't find a forward slash in the askpass executable path, it thinks it has to look for the binary somewhere in the PATH environment variable: See prepare_cmd() here:
https://github.com/git/git/blob/98cedd0233e/run-command.c#L429-L439

The "error: cannot run" part is printed here, after prepare_cmd returns -1, and this is the only case when this happens.
https://github.com/git/git/blob/98cedd0233e/run-command.c#L749-L753

It is possible to reproduce this issue without the git jenkins plugin as well. From CMD, assume C:\askpass.bat exists:
This will result in the same error:

set GIT_ASKPASS=C:\askpass.bat
git clone https://<some_private_repo>.git

This will work (notice the forward slash after C: )

set GIT_ASKPASS=C:/askpass.bat
git clone https://<some_private_repo>.git

It seems like this logic was introduced in this commit in git:

[https://github.com/git/git/commit/321fd823897#diff-7577a5178f8cdc0f719e580577889f04R401-R415

]This is arguably a bug in git, but still, a possible workaround would be to change one of the path separators in the temporary path from a '\' to a '/'

Thanks for investigating, r0mai. Unfortunately, I can't duplicate the results that you are seeing.

I'm running Git for Windows 2.25.1.windows.1 from a Windows 10 command prompt. The Windows 10 environment has the latest feature release installed.

When I create C:\askpass.bat and

set GIT_ASKPASS=C:\askpass.bat
git clone https://github.com/MarkEWaite/tasks.git

the clone succeeds.

If I remove or rename that GIT_ASKPASS file, the clone fails.

Can you provide more details on the case where you're seeing the failure? What version of Git for Windows are you running? Are you running something that is not Git for Windows, like possibly git installed from cygwin?

Hi Mark! I'm using Windows Server 2019, with git 2.21.0 installed using cygwin. This setup has worked in the past with an older version of git (2.7.0).

Thanks. I don't run with cygwin and I don't test with cygwin. I have enough complexities in the git plugin testing environment that I have not been willing to extend git plugin support to cygwin. Git for Windows is the git officially supported by the git client plugin.

Independent of official support, I think it is a very good idea to change the git client plugin to use Unix style '/' in the GIT_ASKPASS. I'm marking this bug report as 'newbie-friendly' so that someone can experiment with writing tests to check the condition and then changing the value of GIT_ASKPASS and SSH_ASKPASS to use Unix style '/' in the path instead of the Windows style '\' .

eicher were you also using cygwin git on the machine which showed this failure?

Thanks Mark!

A fix for this has been merged to git: https://github.com/git/git/commit/05ac8582bc722c8bd3ab7a0cafa681bec198a06d
As far as I can see, it is planned to be released in git 2.27.0.

Fix merged in Git for Windows 2.27.0.