使用vi 修改a.txt 导致 文件的inode会变来变去;
最终在 ~/.vimrc 添加如下
vi 修改文件之后inode不变
原因解释(centos 默认 该值backupcopy auto)
*'backupcopy'* *'bkc'* 'backupcopy' 'bkc' string (Vi default for Unix: "yes", otherwise: "auto") global {not in Vi} When writing a file and a backup is made, this option tells how it's done. This is a comma separated list of words. The main values are: "yes" make a copy of the file and overwrite the original one "no" rename the file and write a new one "auto" one of the previous, what works best Extra values that can be combined with the ones above are: "breaksymlink" always break symlinks when writing "breakhardlink" always break hardlinks when writing Making a copy and overwriting the original file: - Takes extra time to copy the file. + When the file has special attributes, is a (hard/symbolic) link or has a resource fork, all this is preserved. - When the file is a link the backup will have the name of the link, not of the real file. Renaming the file and writing a new one: + It's fast. - Sometimes not all attributes of the file can be copied to the new file. - When the file is a link the new file will not be a link. The "auto" value is the middle way: When Vim sees that renaming file is possible without side effects (the attributes can be passed on and the file is not a link) that is used. When problems are expected, a copy will be made. The "breaksymlink" and "breakhardlink" values can be used in combination with any of "yes", "no" and "auto". When included, they force Vim to always break either symbolic or hard links by doing exactly what the "no" option does, renaming the original file to become the backup and writing a new file in its place. This can be useful for example in source trees where all the files are symbolic or hard links and any changes should stay in the local source tree, not be propagated back to the original source. *crontab* One situation where "no" and "auto" will cause problems: A program that opens a file, invokes Vim to edit that file, and then tests if the open file was changed (through the file descriptor) will check the backup file instead of the newly created file. "crontab -e" is an example. When a copy is made, the original file is truncated and then filled with the new text. This means that protection bits, owner and symbolic links of the original file are unmodified. The backup file however, is a new file, owned by the user who edited the file. The group of the backup is set to the group of the original file. If this fails, the protection bits for the group are made the same as for others. When the file is renamed this is the other way around: The backup has the same attributes of the original file, and the newly written file is owned by the current user. When the file was a (hard/symbolic) link, the new file will not! That's why the "auto" value doesn't rename when the file is a link. The owner and group of the newly written file will be set to the same ones as the original file, but the system may refuse to do this. In that case the "auto" value will again not rename the file.
vim set相关设置见 http://vimdoc.sourceforge.net/htmldoc/options.html#:set