Errors setting up on Windows 7 (g:vundle_last_status undefined)

[MatthiasKauer]

Hi,
this is similar to #399 ,but the fixes there seem to work only for an older version.

My minimal _vimrc

set nocompatible " disable vi compatibility (emulation of old bugs)

"make sure that we can write in temp folder on Windows
"set directory=.,$TEMP

filetype off "vundle needs this; will be turned on later
set runtimepath+=$HOME/vimfiles/bundle/Vundle.vim
let path='~/vimfiles/bundle'
call vundle#begin(path)


Plugin 'gmarik/Vundle.vim' " must be installed manually via git clone on first run!
Plugin 'sjl/gundo.vim'
call vundle#end()            " required

"syntax highlightign and filetype detection
syntax on                           " syntax highlighing
" filetype on                          " try to detect filetypes
filetype plugin indent on    " enable loading indent file for filetype

The fix for the temp folder is disabled, but I'm calling a file from a writable directory (if not: different swap file related errors, but ok). Errors after :PluginInstall are:

I followed the discussion around #294 and #175 . There, people had similar errors and solved them by setting their shell to bash in vim. I am not sure how this applies to my situation on Win7 however.

I also tried the _vimrc suggested in #399 . It didn't work either because I couldn't adjust it to my _vimrc + $Home/vimfiles/bundle setup and vundle#rc seems not to be there anymore.

Now I'm stuck. Can you suggest what I should look into next? Is there maybe an issue with capital letters or punctuation in folder names on Windows (github repo name seems to have changed from vundle to Vundle.vim judging from older issues)?

PS:

C:\Users\matthias.kauer\vimfiles\bundle>git --version
git version 1.9.5.msysgit.0

C:\Users\matthias.kauer\vimfiles\bundle>curl --version
curl 7.30.0 (i386-pc-win32) libcurl/7.30.0 OpenSSL/0.9.8{ zlib/1.2.7
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM SPNEGO SSL SSPI libz

[MatthiasKauer]

tried to add the trailing slash as suggested in #469 but nothing changed.

[ModeEngage]

I've been running into the same issue on Windows 7, and my exhaustive search of the internet has lead me here. Interestingly, I've found another symptom. When I run a :PluginInstall, the .git folder in my current working directory gets wholesale replaced with no user input.

For reference:

> curl --version
curl 7.16.4 (unknown-pc-win32) libcurl/7.16.4
Protocols: tftp ftp telnet dict ldap http file
Features: Largefile
> git version
git version 1.9.5.msysgit.0

[annagrram]

I see nobody replied to this issue for several days, so I decided to jump to a Windows machine and give it a try. Indeed, the problem was there.

After some investigation, I've found that the Antivirus sandbox was the problem.
Try checking your Antivirus settings and make sure to add Vim/gVim and its child processes to the trusted applications.

[MatthiasKauer]

I was going to test turning off my Antivirus, but on my Windows computer at home it wasn't even necessary. Hmm. I'll have to check again on Monday.
This is still on commit 7d9b108.

[MatthiasKauer]

Ok, back at work now; seems like the repo was updated to cfd3b2d in the meantime.
I tested with this and the one before; no big difference on this issue.

On my home installation that shares the configuration files, everything is fine. On my work, the error messages haven't really changed. I did deactivate the virus scanner temporarily, but it didn't help either.

My guess is now that there is an issue with long usernames or dots in usernames and the temp folder where vundle stores some kind of status. At home, I'm 'matthias', at work, I am 'matthias.kauer'.
Does this help somehow?

Note that plugins are installed and appear to work anyway, but it's very confusing.

[annagrram]

Ok. Let's try to narrow down the problem.
Can you do the following steps and report the results?

1. In VIM
   1. :cd $TMP
   2. :w tst
2. In CMD
   1. cd %TMP%
   2. git clone https://github.com/gmarik/Vundle.vim
3. Check the logs of the Antivirus program for blocked operations. Just to make sure.
4. Make sure you don't have other security programs which might interfere.

[ModeEngage]

I had no problem writing to $TMP from vim.

CMD Output:

C:\Users\REDACTED~1\AppData\Local\Temp>git clone https://github.com/gmarik/Vundle.vim
Cloning into 'Vundle.vim'...
remote: Counting objects: 2880, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 2880 (delta 0), reused 0 (delta 0), pack-reused 2873
Receiving objects: 100% (2880/2880), 853.75 KiB | 0 bytes/s, done.
Resolving deltas: 100% (984/984), done.
Checking connectivity... done.

PowerShell Output:

C:\Users\REDACTED\AppData\Local\Temp> git clone https://github.com/gmarik/Vundle.vim
Cloning into 'Vundle.vim'...
remote: Counting objects: 2880, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 2880 (delta 0), reused 0 (delta 0), pack-reused 2873R
Receiving objects: 100% (2880/2880), 853.75 KiB | 902.00 KiB/s, done.
Resolving deltas: 100% (984/984), done.
Checking connectivity... done.

[annagrram]

@ModeEngage Have you chcked your Antivirus (or any other security software) for blocked operations or tried to disable them temporarily?

[ModeEngage]

Looked at all of the logs anti-virus has to offer me -- saw nothing indicating I'd had any operations blocked.

[annagrram]

Another obeservation: I can reproduce this problem also when there's a problem with the Git commands. It doesn't act like in Linux, for example, which is a problem, but let's check. Go to the bundle directory and into Vundle.vim. Then run:

1. git status
2. git remote -v

Please post the result.

[ModeEngage]

C:\Users\redacted\home\vimfiles\bundle\Vundle.vim [master]> git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean
C:\Users\redacted\home\vimfiles\bundle\Vundle.vim [master]> git remote -v
origin  https://github.com/gmarik/Vundle.vim.git (fetch)
origin  https://github.com/gmarik/Vundle.vim.git (push)
C:\Users\redacted\home\vimfiles\bundle\Vundle.vim [master]>

[annagrram]

Looks fine for Vundle.vim
Can you check your other plugins, or disable the rest and just leave Vundle and try to :PluginUpdate?

[MatthiasKauer]

Results are similar on my machine; no issues writing to temp. git output looks identical, but I don't really know what to make of that.

Another idea: is it possible that there are old files created during previous unsuccessful installations that are now lurking somewhere? Can we clear something to get back to a clean slate?

:cd
:pwd
C:\Users\matthias.kauer\AppData\Local\Temp
:w
"tst" [New] 9L, 537C written


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\matthias.kauer>cd %TMP%

C:\Users\MATTHI~1.KAU\AppData\Local\Temp>git clone https://github.com/gmarik/Vun
dle.vim
Cloning into 'Vundle.vim'...
remote: Counting objects: 2880, done.
remote: Total 2880 (delta 0), reused 0 (delta 0), pack-reused 2880
Receiving objects: 100% (2880/2880), 851.76 KiB | 432.00 KiB/s, done.
Resolving deltas: 100% (986/986), done.
Checking connectivity... done.

C:\Users\MATTHI~1.KAU\AppData\Local\Temp>


C:\Users\MATTHI~1.KAU\vimfiles\bundle\Vundle.vim>git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean

C:\Users\MATTHI~1.KAU\vimfiles\bundle\Vundle.vim>git remote -v
origin  https://github.com/gmarik/Vundle.vim.git (fetch)
origin  https://github.com/gmarik/Vundle.vim.git (push)

[MatthiasKauer]

Another test: BundleInstall 'tpope/vim-sensible' worked just fine for me and I even saw the corresponding tmp file that PluginUpdate or Install without argument seems unable to create.
I assume that I'd have to add sensible to my vimrc manually after that, but I didn't test that.

[annagrram]

Vundle seems ok, but the problem could have happened with any other problematic plugin.
To test that, can you please disable all other plugins but Vundle and try to :PluginUpdate?
If that works, try to add one plugin a time until you find the culprit.

[jdevera]

His minimal vimrc contains only two plugins, though.

[jdevera]

@ModeEngage are you sure this is the same problem? What is your minimal vimrc that reproduces your issue? Can you try @MatthiasKauer 's file to see if you get the same errors with it?

[annagrram]

After some more testing, I've found a weird thing.
When I was running the command Vim should build when executing system, I noticed that it doesn't redirect the output to the output/error file but just print it to the screen and the file isn't created. That's why Vim says it can't open the temporary file, because it was never created.

I've made a small change to fix it. Can you please give it a try and say if it works?

[MatthiasKauer]

I'm trying, but it seems you hit the limits of my git abilities.
I cloned the repository again and tried

git checkout windows-output-problem

after that. This didn't work however even though the tutorials I can find adhoc claim that it should. Can you advise?

[annagrram]

Sure :)

1. Open cmd
2. cd <Vundle location>
3. git remote add av3r4ge https://github.com/av3r4ge/Vundle.vim.git
4. git fetch av3r4ge
5. git checkout windows-output-problem
6. Reopen Vim and try.

Note that it should fail to update Vundle. That's ok, but at least it should fail in a good manner, i.e. without that annoying error and with an exclamation mark in the Vundle window.

After that, git checkout master, and everything will return to normal.
If you want to clean it completely then:

1. git remote remove av3r4ge
2. git branch -D windows-output-problem

[MatthiasKauer]

Ok, I pulled from your forked repository now. I had missed that this isn't the same url anymore.
I then verified that my local version has the additional parentheses you added in vundle/installer.vim. Unfortunately, the behavior is no different from what it was on the original vundle master branch.

Also, I note again that it doesn't fail to update. Well, it does installs anyway that work afterwards. Whether it would update, I haven't really checked thus far. I don't get to see the final log, so it's a bit tricky.
Overall, it seems that it only has trouble creating these tmp files and then throws an error over it.

[annagrram]

Hi. I'm sorry for the late response.
This gets more frustrating every day, but we'll manage to figure this out.

Just to test the hypothesis of my fix, try to run both of the following commands in a git repository after you checkout some arbitrary commit (e.g. git checkout HEAD~2). I'll assume Vundle is placed in the default location ($HOME/vimfiles/bundle/Vundle.vim)

• (cd /d "$HOME/vimfiles/bundle/Vundle.vim" && git pull && git submodule update --init --recursive > "$HOME/tst.txt" 2>&1) This should echo an error to the console and not create $HOME/tst.txt
• ((cd /d "$HOME/vimfiles/bundle/Vundle.vim" && git pull && git submodule update --init --recursive) > "$HOME/tst.txt" 2>&1) This shouldn't echo an error to the console and create $HOME/tst.txt with the error message

If the above works, please verify again that you checked out my branch in the location Vundle is loaded from and reopened Vim after you checked it out.

Also, can you please post the output of the following settings:

• :set shell?
• :set shellcmdflag?
• :set shellxquote?
• :set shellredir?

Those are the settings used to build the command system is going to execute.

If this still doesn't work, we can try to analyze what really happens there with a bit more advanced tool. I'll try to explain the basics of its usage.

The tool is called Procmon (Process Monitor) and is part of the Sysinternals tools. You can download it from here.

This tool will allow us to see all the accesses to the filesystem, registry, network, etc.
I recommend opening it with the /NoExec option.
When you open it, you'll notice some icons at the top.
The important ones are:

• Magnifying glass - Stop and start monitoring
• Eraser - Clean
• Diamond - Setting up filters
• Registry, Archive, ... - Types of monitoring

Try to set a filter for 'Path' including 'Temp', start monitoring, reopen Vim and try to update the plugins.
After it fails, stop the monitoring and browse the results. You can right-click any field and exclude it. For example, you can right-click 'SUCCESS' and choose to exclude it so it won't interrupt in finding the issue.

You can try to analyze this yourself or save the results and link them here. But notice it contains a lot of information about programs running and paths in your system, especially if you choose to save everything and not just the filtered results.

I hope it will bring us closer to finding a solution to this problem.

[ModeEngage]

I've been stricken with the plague -- I'll provide more data when I'm feeling less like a corpse.

[MatthiasKauer]

All the best @ModeEngage ! Thanks for bearing with us @Av3r4ge
I started testing the commands that you suggested and ran into the following trouble:
$var doesn't expand on my machine, %var% does. I also found that %HOME% is just not set here, it's %USERPROFILE%.
After amending the first input you suggested accordingly, it ran without error in spite of your prognosis. Did I fix away what you wanted to see or are we on to something here now?

afterthought: I added HOME as a user variable like here but it didn't change anything.

[annagrram]

My bad, I'm too used to Unix notation that I wrote $var automatically instead of %var%.
Well, it ran without an error maybe because you haven't detached HEAD (for example, git checkout HEAD~2).
But, you can see that in the first time it gives the output 'Already up-to-date.' and in the second time there is no output.
Please remove the file in %HOME%\tst.txt and run the commands again to see if the file is created after the first or second command (should not exist after first, should exist after second),

One more thing, if you don't have %HOME% set, from where does it load Vundle?

set runtimepath+=$HOME/vimfiles/bundle/Vundle.vim
let path='~/vimfiles/bundle'

You have these two lines in your .vimrc. What $HOME and ~ expand to in Vim?

[clausreinke]

The error handling is attrocious, which tends to obscure error causes. I also suspect that windows users who get things to work don't report back with suggestion for improvements. I've just started with vundle, and have run into so many issues that i'm not sure i'll stay with it. Fortunately, code quality looks better than the behaviour suggests, but the combination of brittleness and error handling leaves a bad initial impression for windows users (still struggling with a variation of #509 myself).

That last status variable should be initialized before use, but the game is already lost when the temp file can't be read.

Vundle tries to keep a log, but when a system call aborts, the cmd that fails hasn't been written to the log yet. once that is fixed (Swap a few lines in the vundle code), you can extract the failing cmd from the log and run it in a standalone cmd window to inspect errors (if the plugin name is wrong, there may be a prompt that you never get to see otherwise).

[clausreinke]

This seems to help a little (though I'm still seeing bugs):

1. debugging help: in Vim, :set shellcmdflag=/k - this will keep the cmd window around after executing system calls, so you can easily check the commands that are passed (the windows will be minified, so watch your icon tray, and you need to close the cmd windows explicitly to allow vim to proceed)
2. since system call arguments are passed as parameters to cmd /k, it seems necessary to escape them (that also takes care of the grouping @Av3r4ge was aiming at via his () patch). change s:system as follows:

 func! s:system(cmd) abort
-  return system(a:cmd)
+  let slash = &shellslash
+  set noshellslash
+  let result = system(shellescape(a:cmd))
+  if slash | set shellslash | endif
+  return result
 endf

This will keep your shellslash setting, while getting the unmodified shellescape behaviour (btw, escaping " for cmd means doubling to "", unlike the unixy \" used by vundle#installer#shellesc)

[clausreinke]

Since quoting/escaping on windows is no fun (and application-dependent), here is a link to cmd docs (scroll down to "Remarks"):
https://technet.microsoft.com/de-de/library/cc771320(v=ws.10).aspx

So, wrapping a:cmd in "" might also suffice? Anyway, my patch seems to work for me (windows 7). Any unix testers - do we need a conditional or does the same code work?

[MatthiasKauer]

$HOME expands fine within vim to %USERPROFILE%.

Executing

(cd /d "%USERPROFILE%/vimfiles/bundle/Vundle.vim" && git pull && git submodule update --init --recursive > "%USERPROFILE%/tst.txt" 2>&1)

creates an empty tst.txt.

((cd /d "%USERPROFILE%/vimfiles/bundle/Vundle.vim" && git pull && git submodule update --init --recursive) > "%USERPROFILE%/tst.txt" 2>&1)

creates a tst.txt with 'already up to date'

I also tried the patch that clausreinke offered. It successfully suppresses the errors and certainly improves the situation. Thank you!

Hitting 'u' for the update log at the end still won't work however (error complains that some .tmp couldn't be found'). Should we investigate this further or should we be happy with this?

[clausreinke]

@MatthiasKauer that is correct.

[MatthiasKauer]

Ok, I did what I had described 2 posts up with the minimal _vimrc from my first post (I amended 'gmarik/Vundle.vim' to 'clausreinke/Vundle.vim'). It worked well with that setup (including the log I get when I hit 'l' at the end).
Further testing on this machine in my larger vimrc looks good as well.
I didn't test whether your changes break Linux setups, but I'm happy.

[MatthiasKauer]

I'm afraid I'm back with bad news; I just tested branch collected_fixes on my home machine assuming that the standard branch wouldn't work there either. However, as odd as it sounds, the opposite was the case. Errors about git clone not being a command on the new branch; everything working as expected on gmarik commit cfd3b2d.
I'm trying to figure out what's different between the two machines now.
Home machine: Win7 Home, in cmd.exe: ver returns Version 6.1.7601, gvim 7.4, compiled Aug 10 2013. Not sure what else to look at. Will report back from work on Monday.

[clausreinke]

Try

:echo system('echo "hi" && echo "ho"')
:echo system('"echo "hi" && echo "ho""')

Unless the first suddenly starts working, and the second failing, the patch is necessary. Note also that your error message is new, so you should investigate that in more detail (set shellcmdflag=/k) on your home machine.

[MatthiasKauer]

still testing on my home machine:
the first message only displays "ho", the second says echo is not recognized.
After adding \k, cmd boxes pop up in the background; now the first one shows "hi" (no longer ho) in the cmd box and "ho" back in the vim message.The second doesn't show anything in command box, but in vim I still see that it's not a recognized cmd.

[clausreinke]

Wow, that sounds completely broken. The first is expected (only the output of the second echo is captured and returned to vim), the second has changed (looks like excessive quoting).

And if you're running a default vim setup without modifications, that must be change in vim itself (from 7.3 to 7.4). We need to find the relevant vim patch, and how to test for it. Assuming that patch was a fix, could you try wrapping the command in () instead of ""?

Ps. The master branch of my fork has two commits that shouldn't be there, but i'm still not sure why it would be working for you, under these conditions.

[clausreinke]

Probably relevant: https://github.com/airblade/vim-system-escape
And the vim patches/discussion it links to. Looks like fun:-(
looks like we need a form that works with either version of vim, though newer vims should indeed work better without patch (they internalize the patch behaviour).

[clausreinke]

have now installed vim 7.4 and can confirm extensive changes in the way system arguments are escaped for windows. I've updated the fork/pull request #589 to account for version difference and the two vim patches that seem to be responsible. This now works for me with an old vim 7.3 and a new vim 7.4 - I haven't tested with a new vim 7.3 (with the relevant patches).

[MatthiasKauer]

Back on my work PC where vim was still 7.3. I can confirm that Claus' changes are working (I pulled the newest collected_fixes). I have now upgraded to 7.4 and his changes are still working.
Looks great to me!

[ismail]

I see that #589 is not merged and I can still reproduce the same problem with latest Vundle.git and vim 7.4.769

[MatthiasKauer]

Where are you getting the longer version number from? I've been happy since I switched to 7.4 on multiple devices although I haven't updated vundle in a while, I suppose.

[ismail]

See https://tuxproject.de/projects/vim/

[apple601601601]

I've also came across this problem and switch to vim 7.4 also solved my problem. Just don't know how does the update fix it..

[MatthiasKauer]

@apple601601601 Consider the links that clausreinke posted on April 13; there appear to have been major changes in vim's string handling between 7.3 and 7.4.

[eckes]

Same problem here, but the hint given by @clausreinke pointed me to the right direction:
:set shellcmdflag=/k
leaves the command window open. There I found that no connection could be made to Github at all because the proxy wasn't running.
I'm behind an authenticating corporate proxy and use CNTLM in order to access the proxy with my credentials. The CNTLM service wasn't started, so I couldn't connect.

[ctataryn]

I had similar problems to this. I don't know if it was my virus checker or what, but when I went into Control Panel -> System -> Advanced system settings -> Environment Variables and I changed my TMP and TEMP variables from %USERPROFILE%\AppData\Local\Temp to C:\temp everything started working again after I relaunched vim and typed :PluginInstall

[ctataryn]

Hmm it appears I've spoken too soon... That did indeed solve my problem for when I launched gVim from the Start Menu shortcut. However, If I were to launch gVim from GitBash, I'd get those same E484 errors. If I just ran the plain-jane vim terminal version from GitBash it would work, but gVim still had that same problem. I had to follow the instructions listed here in order to solve across all various launch methods:

http://stackoverflow.com/a/10622083/33689

Namely:

if has("win16") || has("win32") || has("win64")
  if &shell=~#'bash$'
    set shell=$COMSPEC " sets shell to correct path for cmd.exe
  endif
endif

[lucastheisen]

I had the same problems stemming from the fact that I have configured PowerShell as my shell:

if has("win32") || has("gui_win32")
    if executable("PowerShell")
        " Set PowerShell as the shell for running external !commands
        " http://stackoverflow.com/questions/7605917/system-with-powershell-in-vim
        set shell=PowerShell
        set shellcmdflag=-NoLogo\ -NoProfile\ -NonInteractive\ -ExecutionPolicy\ RemoteSigned\ -Command
        set shellquote=\"
        " shellxquote must be a literal space character.
        set shellxquote=
    endif
endif

I am able to work around this by overriding PluginInstall thusly:

function VundlePluginInstall(...)
    let shell = &shell
    let shellcmdflag = &shellcmdflag
    let shellquote = &shellquote
    let shellxquote = &shellxquote

    set shell=C:\Windows\system32\cmd.exe
    set shellcmdflag=/c
    set shellquote=
    set shellxquote=(

    call call('vundle#installer#new', a:000)

    set shell=shell
    set shellcmdflag=shellcmdflag
    set shellquote=shellquote
    set shellxquote=shellxquote
endfunction

command! -nargs=* -bang -complete=custom,vundle#scripts#complete PluginInstall
\ call VundlePluginInstall('!' == '<bang>', <f-args>)

Would love to know if there is a better approach for integrating PowerShell.

[airelil]

Hi guys. Just got similar problems. Suddenly started getting a lot of
E484: Can't open file C:\Users\DELL\AppData\Local\Temp\VIoDF89.tmp on my Win8 machine.
Tried the :set shellcmdflag=/k and I discovered that many of my git repos are in the "dirty" state.
git status for almost any plugin there were modified files. Seems the problem is gone after I manually ran:
git checkout -f HEAD && git pull.

[magicstep]

Following @airelil advice I run the following command in each plugin directory:
git checkout -f HEAD && git pull
and it helped, PluginUpdate goes without errors. I think it's because there's nothing to update after doing manual update via git.
I think this would work too: delete all plugin directories (or at least troubling ones) except Vundle and run PluginInstall since I could easily install new plugins but couldn't update some of them.

[Fisher-Chen]

Same issue.
vim: 8.0.1616
git: 2.15.1.windows.2
curl: 7.59.0 (x86_64-pc-win32)
Changed environment TEMP to c:\Temp.

Another plugin manager: Minimalist Vim Plugin Manager is working fine.

[jk2K]

maybe you need to reinstall Git for Windows, https://git-scm.com/downloads

[craigforr]

I had the same errors shown in the original post while moving from Vim 7.4 to 8.1 on Windows 10.

Problem:

On my system the problem appears to have stemmed from the fact that I did not have Git for Windows installed with the option to Use Git from the Windows Command Prompt, per the instructions in Step 2 under Git for Windows in the Vundle for Windows article.

Solution:

1. Upgraded to the latest version of the official Git installer for Windows, making certain to check the radio option (*) Use Git from the Windows Command Prompt during the install.
2. From a Command Prompt, run the following commands:

mkdir %USERPROFILE%\vimfiles\bundle
pushd %USERPROFILE%\vimfiles\bundle
git clone https://github.com/VundleVim/Vundle.vim.git

3. Added the following lines to a fresh _vimrc in %USERPROFILE%:

set nocompatible
filetype off
set rtp+=$HOME/vimfiles/bundle/Vundle.vim/
call vundle#begin('$USERPROFILE/vimfiles/bundle/')
Plugin 'VundleVim/Vundle.vim'
call vundle#end()

4. Opened gVim, and ran :PluginInstall to verify Vundle base functionality.
5. Updated vimrc with additional plugins. I added mine one at a time---saving the config, reopening, running install---just to make certain none of the individual plugins had issues.
6. Add any remaining Vim configuration to %USERPROFILE%\_vimrc.

So far, everything is working fine.

The Vundle for Windows wiki page mentions that curl is no longer packaged with Git, but the official installer does include it:

C:\> "%ProgramFiles%\Git\mingw64\bin\curl.exe" --version
curl 7.60.0 (x86_64-w64-mingw32) libcurl/7.60.0 OpenSSL/1.0.2o (WinSSL) zlib/1.2.11 libidn2/2.0.5 nghttp2/1.32.0
Release-Date: 2018-05-16
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy MultiSSL Metalink

If you encounter curl related errors, you may need to add it to your PATH.

[sleepyhollo]

Same issue.
vim: 8.0.1616
git: 2.15.1.windows.2
curl: 7.59.0 (x86_64-pc-win32)
Changed environment TEMP to c:\Temp.

Another plugin manager: Minimalist Vim Plugin Manager is working fine.

I am getting this same error. I am in windows 10. I moved my temp folder without any success. Added gvim to environmental variables, still nothing. I have both python and python3 included in my vim installation. I also tried running gvim as administrator and than trying to install the plugins. still no cigar.

Response of `gvim --version``

VIM - Vi IMproved 8.1 (2018 May 18, compiled May 18 2018 18:36:07)
MS-Windows 32-bit GUI version with OLE support

Response of git --version from cmd

git version 2.19.2.windows.1

Response of curl --version from cmd

curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL

Let me know if other details are required.

Update 1: Reinstalled git, still the same problem. It works when i use the command prompt vim (and not gvim); so gvim is what maybe causing problems. For now, I will use command prompt vim to update plugins and gvim for work i guess.

Update 2: Apparently it was my antivirus quarantining vimrun.exe. It works now. YAY!

[tizee]

I've encountered this issue since I quit the cmd.exe when its downloading was unfinished.
I had tried changing the %TEMP% and %TMP% or resetting the shell options but neither of those works. Then I came up with this idea that have I tried to delete all the incomplete vim under bundle\.
After I deleted that plugin directory, the error was gone.
Hope my solution will help someone.

[AMJNutreco]

I've had this issue today and found another problem/solution.

My setup:
Windows 11
Vim 9.0.49

I solved it by commenting this line in my .vimrc:
set shell=powershell.exe

Everything was working fine up to today, when I tried to execute VundleUpdate. After reading some of your comments I remembered the last change I did in my .vimrc, which was the line I mentioned before. After commenting out that line, VundleUpdate runs again without any issue.

Hope it helps.