Nathan Coulter wrote:
bug report
==========
version:
VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:23:43)
MS-Windows 32 bit GUI version with OLE support
problem:
Writing to a file on a windows share where the underlying filesystem
supports hard links, modifying a file using gvim (w command) causes
the file to
acquire a new inode. Contrast with the behavior of notepad.exe
(file - save), which
respects the hard link, keeping the inode intact.
Apparently no patches were included: there are 201 official patches to date
for Vim 7.0, the latest was a few days ago (see their "table of contents" at
http://ftp.vim.org/pub/vim/patches/7.0/ ). Get updated distributions of Vim
for Windows at
https://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721
I think this behaviour is related to how Vim handles backups. Set 'backupcopy'
(q.v.) to "yes" in order to prevent renaming of the existing file:
set bkc=yes
Vim copies the file to create a backup, then edits the "old" file
Advantage: all permission and ownership bits are conserved
set bkc=no
Vim renames the existing file to create a backup, then edits a new file
with the old name
advantage: faster
set bkc=auto " default
same as "no" except when Vim can detect that this could cause problems
(e.g., sees that the existing file is a link).
advantage: tries to combine the advantages of the other two.
Apparently in the case you mention, Vim-for-Windows doesn't detect that the
target file is a hard link.
Best regards,
Tony.
--
"Every group has a couple of experts. And every group has at least one
idiot. Thus are balance and harmony (and discord) maintained. It's
sometimes hard to remember this in the bulk of the flamewars that all
of the hassle and pain is generally caused by one or two
highly-motivated, caustic twits."
-- Chuq Von Rospach, about Usenet
