Re: gvim, Windows NAS share of a unix file system, hard links
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. What is the 'backupcopy' option set to? It should be auto, then Vim should be able to recognize hard links on NTFS filesystems. 'backupcopy' is set to auto. The hard link is not on an NTFS filesystem, but on a network drive shared from a NAS device, Network Appliance OnTap 7.0.3p4, configured as a unix filesystem. I access this NAS filesystem location from linux and windows computers. From a windows computer, a w command in Gvim cause assignment of a new inode, whereas file -save in notepad.exe retains the file inode, keeping the hard link intact. Ah, well, Vim can't know there is a hard link then. You better set 'backupcopy' to yes. Or avoid hard links, there will probably more trouble with them. -- hundred-and-one symptoms of being an internet addict: 208. Your goals for the future are obtaining an T1 connection and a 130 gig hard drive. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: gvim, Windows NAS share of a unix file system, hard links
---Original Message--- From: Bram Moolenaar [EMAIL PROTECTED] Subject: Re: gvim, Windows NAS share of a unix file system, hard links Sent: 2007-02-25 09:42 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. What is the 'backupcopy' option set to? It should be auto, then Vim should be able to recognize hard links on NTFS filesystems. 'backupcopy' is set to auto. The hard link is not on an NTFS filesystem, but on a network drive shared from a NAS device, Network Appliance OnTap 7.0.3p4, configured as a unix filesystem. I access this NAS filesystem location from linux and windows computers. From a windows computer, a w command in Gvim cause assignment of a new inode, whereas file -save in notepad.exe retains the file inode, keeping the hard link intact. -- Nathan Coulter
Re: gvim, Windows NAS share of a unix file system, hard links
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. What is the 'backupcopy' option set to? It should be auto, then Vim should be able to recognize hard links on NTFS filesystems. -- A computer program does what you tell it to do, not what you want it to do. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: gvim, Windows NAS share of a unix file system, hard links
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=43866package_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
