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).


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

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.

  • What happens when you use a hard link instead? – paradroid Mar 10 '11 at 16:30
  • Works with hardlinks AND backup. I just had to remove the readonly flag. – M'vy Mar 10 '11 at 16:33
  • 1
    Doesn't seem to work on my machine: Windows 7 x64. When I save the file I always lose the symlink. In my vimrc I have: set nobackup and set nowritebackup. – Thiru Mar 12 '11 at 0:54
  • I've just tested on a windows 7 x32. It works even better since I can do it with symlinks AND backup (and of course hardlinks). Vim version is 7.3.46. – M'vy Mar 12 '11 at 1:03

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):



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

  • The bug was fixed in 7.3.1182 (which I think is the same patch you linked) but Vim 7.4 is the first win32 release on vim.org to include this patch (released 2013-08-10). – idbrii Aug 21 '14 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.