VIM destroys symbolic links under Windows

Question

It seems that when working with a file in VIM it primarily uses a backup version of the file then overwrites the original on save. This is a problem when using symbolic links under Windows (e.g. mklink link_path target_path) as it destroys the symbolic link.

Does anyone know a way around this? I've already seen this in the FAQ which talks specifically to this issue but the recommended workaround doesn't work. Maybe it did at some point but not for Vim 7.3 (under Windows 7 x64).

Answer 1

This bug was fixed in 7.3.1182. Vim 7.4 is the first release on vim.org to include this patch (released 2013-08-10).

To support older versions of vim, you can use something like this in your vimrc:

" Writing files on Windows doesn't preserve file attributes seen via cygwin
" (presumably because the created backup copy didn't inherit them correctly).
if has('win32') && v:version < 704
    set backupcopy=yes
endif

Answer 2

Hum on windows, the symlink is moved to create the backup file. Then the corrections are written with the first name. (NB: The temp file is still linked to the original file)

They say that "The only way to fix this in the current version is not making a backup file, by :set nobackup nowritebackup "

Is that the workaround you were talking about? Because this is working on my vista.

EDIT: Of course, you won't have backups.

Answer 3

If you still need backups, you can use:

set bkc=yes

(why? read :h bkc) it solves the problem on Windows.

If the original file is read-only, you have to remove the read-only flag before opening the file. Alternatively while editing the file, you can remove the read-only flag, and run :set modifiable then save it.

There is an alternative using resolve() to resolve the path pointed to by the link. I use version7.3 and resolve() seems to fail to resolve links made with the mklink command on Windows):

http://vim.1045645.n5.nabble.com/How-do-I-make-e-path-completion-follow-symlinks-td1175347.html

Answer 4

Using the backupcopy option can be nicer if you only have certain files or directories in which you expect to find symbolic links. For example, I use sym links to edit runtime files in my vim source code repository and see the changes reflected in my ~/vimfiles directory:

" for some reason, backupcopy=auto doesn't work on Windows to keep
" symbolic links. I use these in my vimfiles directory to override some
" runtime files which I really edit in the vim source repository.
autocmd BufWritePre ~/vimfiles/* set backupcopy=yes
autocmd BufWritePost ~/vimfiles/* set backupcopy&

Note that the default value of 'backupcopy' is SUPPOSED TO keep symbolic links when writing, according to the :help.

See http://groups.google.com/group/vim_dev/browse_thread/thread/a85f18df1b543fec