331576717 / vim

Automatically exported from code.google.com/p/vim
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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