Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

out of the box, gVim 7.3.46 for Win32 cannot write swap files on Windows 7 #28

Closed
GoogleCodeExporter opened this issue Aug 18, 2015 · 18 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?

1. install Vim on Windows 7
2. start gVim
3. insert text in the buffer

What is the expected output? What do you see instead?

The unexpected output is the message:
E303: Unable to open swap file for "[No name]", recovery impossible

What version of the product are you using? On what operating system?

Vim 7.3.46, self identifying as:
Vim 7.3 (2010 Aug 15, compiled oct 27 2010 17:59:02)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-46
Compiled by Bram@KIBAALE

Please provide any additional information below.

gVim uses the default setting for the "directory" option, that is, it gets 
".,c:\\tmp,c:\\temp", which originates from os_dos.h.

Unfortunately, none of these were writable on a vanilla Windows 7 install. cwd 
is C:\Windows\system32, and neither c:\tmp nor c:\temp exist.

This differs from the behavior of the identical installer package on Windows 
XP. cwd on Windows XP seems to originate from the HOME environment variable, 
which is writable.

A good solution would cause installs on Windows 7 to have cwd be from HOME on 
startup, just as on Windows XP.

Changing the "Compatibility Mode" for Vim under Windows 7 to "Windows XP 
(Service Pack 3)" does not correct cwd, so it is not a useful workaround. The 
same is true of changing "Start In" on the gVim shortcut from empty to %HOME%.

Adding a "set directory" to .vimrc and appending a writable directory is a good 
temporary workaround. Both of these worked:

set directory+=$HOME
set directory+=$TEMP

Original issue reported on code.google.com by metaed on 21 Oct 2011 at 6:53

@GoogleCodeExporter
Copy link
Author

As you can see from the "compiled by" line, that Vim version is about one year 
old, which, for a Vim executable, is quite old.
Try repeating the experiment with the latest Vim (or gvim) 7.3.346 as can be 
downloaded in the form of a Windows self-installer from 
http://sourceforge.net/projects/cream/files/Vim/

Notes:
  1. IIUC you should run the installer with sysadmin privileges).
  2. This Vim distribution is found on the Cream _site_ but it is not the Cream _product_. Among Vim old-timers, it is known under the nickname "Vim without Cream".

Original comment by antoine....@gmail.com on 21 Oct 2011 at 9:06

@GoogleCodeExporter
Copy link
Author

I have now downloaded 7.3.346 for the purpose of trying to reproduce the 
problem. I was able to reproduce the problem in 7.3.346 also.

Out of curiosity, when you characterize 7.3.46 as quite old, that leads me to 
ask, is there a newer general release for Win32? I was under the impression 
that 7.3.46 was it, because it links from "http://www.vim.org/download.php#pc".


Cheers!

Original comment by metaed on 21 Oct 2011 at 9:37

@GoogleCodeExporter
Copy link
Author

New releases (with precompiled Windows binaries) rarely appear on www.vim.org 
unless there is, well, a new release: the next one will probably be Vim 7.4, or 
Vim 8.0 if there is no Vim 7.4. In the meantime, the Vim source is continuously 
updated on Vim's public Mercurial repository, and Steve Hall (manager of the 
Cream site) maintains an unofficial but fairly up-to-date Vim distribution 
compiled for Windows with rarely more than a week's delay on the latest 
sources; that distribution also includes the latest version of the runtime 
files known at compile-time.

Original comment by antoine....@gmail.com on 22 Oct 2011 at 8:48

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

I was just upgraded to Windows 7 at work and ran into this issue.

The problem is that Vim defaults the 'directory' option to ".,C:\TMP,C:\Temp" 
but these directories either do not exist or are not writeable.

Vim should instead use the $TMP and $TEMP environment variables instead of 
hard-coded paths.

For now I have a workaround for the problem in my .vimrc like this:

http://cfc.kizzx2.com/index.php/gvim-e303-unable-to-open-swap-file-for-no-name-r
ecovery-impossible/

Original comment by fritzoph...@gmail.com on 15 Feb 2013 at 7:45

@GoogleCodeExporter
Copy link
Author

I just installed vim 7.4 and the problem remains.

The solution:
In vmrc, the following lines exists by default,in lines 14 y 24 I use " instead 
single quotes where exists < or >.
This appeared to be related to escape correctly.
Escuse my English.


1 set diffexpr=MyDiff()
2 function MyDiff()
3  let opt = '-a --binary '
4  if &diffopt =~ 'icase' | let opt = opt . '-i ' | endif
5  if &diffopt =~ 'iwhite' | let opt = opt . '-b ' | endif
6  let arg1 = v:fname_in
7  if arg1 =~ ' ' | let arg1 = '"' . arg1 . '"' | endif
8  let arg2 = v:fname_new
9  if arg2 =~ ' ' | let arg2 = '"' . arg2 . '"' | endif
10  let arg3 = v:fname_out
11  if arg3 =~ ' ' | let arg3 = '"' . arg3 . '"' | endif
12  let eq = ''
13  if $VIMRUNTIME =~ ' '
14    if &sh =~ "\<cmd"
15      let cmd = '""' . $VIMRUNTIME . '\diff"'
16      let eq = '"'
17    else
18      let cmd = substitute($VIMRUNTIME, ' ', '" ', '') . '\diff"'
19    endif
20  else
21  let cmd = $VIMRUNTIME . '\diff'
22  endif
23  silent execute '!' . cmd . ' ' . opt . arg1 . ' ' . arg2 . " > " . arg3 . eq
24 endfunction

Original comment by fvelasqu...@gmail.com on 11 Aug 2013 at 3:46

@GoogleCodeExporter
Copy link
Author

I do not see the problem "out of the box".
Starting gVim from the desktop results in a swap file 
"c:\Users\bram\Desktop\_.swp".
How did you start gVim then?
How did you manage to start in a directory that is not writable?

Original comment by brammool...@gmail.com on 11 Aug 2013 at 5:51

@GoogleCodeExporter
Copy link
Author

Starting Vim from the start menu (which admittedly I've never done in 15+years 
using it until just now) sets the current working directory to 
C:\Windows\system32, which is not writeable to normal users, thus giving the 
swap file error.  It's not a common usage scenario, but the fix is pretty 
simple.

The root issue is that neither C:\TMP and C:\Temp exist by default on Windows 
and haven't for a long time, so the swap file fails in any folder that the user 
can't write to.  The default value of directory on Win32 should probably be 
".,$TMP,$TEMP" (or maybe ".,C:\TMP,C:\Temp,$TMP,$TEMP" for maximum backwards 
compatibility with older versions of Windows. I'm not sure when exactly the 
change of temp dirs happened).

Original comment by ab...@yahoo.com on 20 Sep 2013 at 5:43

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

This problem is occurring because the 'Start In' field is blank in the 
shortcuts in the Start menu. When a value isn't specified for that field, the 
program that is started will use the working directory of the parent process. 
The working directory is C:\Windows\system32 for the Start menu.

As a temporary workaround, you can edit each Vim icon in your Start menu and 
add "%HOMEDRIVE%%HOMEPATH%" to the Start In field. This will ensure that Vim 
starts with the working directory set to the home directory of the user who 
started the program. The %HOMEDRIVE% variable will expand to something like C: 
and %HOMEPATH% to \Users\Username where Username is the user who launched the 
process. This is the same method used when launching the command prompt from 
the start menu, for example.

For a permanent solution, line 1778 of src/dosinst.c needs to be changed to

    #define WORKDIR "%HOMEDRIVE%%HOMEPATH%"

so that the value is set when the shortcuts are installed to the Start menu.

Original comment by mplistar...@gmail.com on 6 Nov 2013 at 6:04

@GoogleCodeExporter
Copy link
Author

The trigger may be that the current directory is not writable...but when the 
current directory is not writable, Vim has BAD fallback locations defined. It 
should fall back to the environment variables %TEMP% or %TMP% but instead falls 
back to C:\TEMP and C:\TMP which don't exist on Windows 7. As discussed earlier.

Original comment by fritzoph...@gmail.com on 6 Nov 2013 at 6:27

@GoogleCodeExporter
Copy link
Author

This patch will use environment variables for the temp directories for both 
'directory' and 'backupdir' options. This way on a fresh Windows 7 install, the 
user should always have write access to at least one of the directories in 
these options. This is needed even after the change to the installer "start in" 
path in patch 7.4.077, because you can still start Vim from non-writable 
directories.

Original comment by fritzoph...@gmail.com on 14 Nov 2013 at 4:38

Attachments:

@GoogleCodeExporter
Copy link
Author

I'm hitting this on a relatively new Windows 7 install: anything that requires 
Vim to use temporary files (diff, shell commands) results in undesirable 
behaviour (E483 Can't get temp file name, or a diff that fails to highlight 
differences).
I've tried
* setting my environment variables
* including let $TMP="c:\temp" & let $TEMP="c:\temp" in my _vimrc
* disabling UAC & rebooting
* setting broad access permissions on the Vim install folder
* changing the 'Start in' directory of the Vim shortcut icon (to My Documents)
* including set directory=.,$TMP,$TEMP in my _vimrc
All to no avail I'm afraid.  Not sure how else I can tell Vim to locate the 
temp files.

Original comment by leed...@gmail.com on 21 Feb 2014 at 10:38

@GoogleCodeExporter
Copy link
Author

If you do this (all by itself with no other changes) in your _vimrc, and your 
_vimrc is getting sourced, then it should work for you:

  set directory=.,$TMP,$TEMP

But you say this does not work? What does ":verbose set dir?" tell you? It 
should point to expanded directory names. Note that C:\TEMP and C:\TMP do not 
exist on a default Windows 7 install, so if you still had the manual setting of 
$TEMP and $TMP in your _vimrc when you set your directory, that would have 
failed.

Also, have you tried installing a Vim version >= 7.4.112? That is the version 
which fixed this particular issue (by making the defaults for 'dir' and 'bdir' 
include the temp directories).

Original comment by fritzoph...@gmail.com on 21 Feb 2014 at 6:57

@GoogleCodeExporter
Copy link
Author

Actually, you might have a different issue. Does your _vimrc change the 
settings for 'shell', 'shellxquote', and/or 'shellcmdflag'? Vim's quoting 
behavior on Windows changed significantly between 7.3 and 7.4, so that old 
workarounds for the atrocious quoting rules in the cmd.exe shell no longer work 
and will cause errors like not being able to read temp files or not being able 
to view diffs.

Original comment by fritzoph...@gmail.com on 21 Feb 2014 at 6:59

@GoogleCodeExporter
Copy link
Author

With apologies to fritz... for the slow reply, installing version 7.4.103 from 
the Cream Sourceforge repository appears to resolve my issues.

Original comment by leed...@gmail.com on 27 Feb 2014 at 8:58

@GoogleCodeExporter
Copy link
Author

Fixed by 7.4.112

Original comment by chrisbr...@googlemail.com on 30 Sep 2014 at 9:23

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

I also found a solution that seems to work for all of the windows 7 gvim74 
utilities.

In the C:\Program Files (x86)\Vim\vim74\mswin.vim file I inserted this command 
after the " Last change:    2012 Jul 25
(line 5)
set directory+=%TEMP%

Now when I open gvim as any user, :set directory? shows

  directory=.,c:\tmp,c:\temp,~\AppData\Local\Temp

which is writable, and does not ignore my "start in" settings for the icon when 
opened from the desktop or the start menu.  I still modify the "start in" 
shortcut attribute to %HOMEDRIVE%%HOMEPATH%, just so I am not in 
c:\windows\system32 when opening a new document.

The downside, is remembering this setting until a writable directory is the 
default installer setting for gVim.

Original comment by danlis...@gmail.com on 5 Oct 2014 at 10:09

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant