3

I use Vim 8.2 to edit my files in my Ubuntu 18.04. When I open a file, do some changes and quit with Vim, the inode number of this file will be changed.

As my understanding, it's because the backup mechanism of my Vim is enabled, so each edition will create a new file (.swp file) to replace the old one. A new file has a new inode number. That's it.

But I found something weird.

As you can see as below, after the first vim 11.cpp, the inode has changed, 409980 became 409978. However, after creating a hard link for the file 11.cpp, no matter how I modify the file 11.cpp with my Vim, its inode number won't change anymore. And if I delete the hard link xxx, its inode number will be changed by each edition of my Vim again.

This really makes me confused.

$ ll -i ./11.cpp
409980 -rw-rw-r-- 1 zyh zyh 504 Dec 22 17:23 ./11.cpp

$ vim 11.cpp     # append a string "abc" to the file 11.cpp
$ ll -i ./11.cpp
409978 -rw-rw-r-- 1 zyh zyh 508 Dec 22 17:25 ./11.cpp


$ vim ./11.cpp   # remove the appended "abc"
$ ll -i ./11.cpp
409980 -rw-rw-r-- 1 zyh zyh 504 Dec 22 17:26 ./11.cpp


$ ln ./11.cpp ./xxx   # create a hard link
$ ll -i ./11.cpp
409980 -rw-rw-r-- 2 zyh zyh 504 Dec 22 17:26 ./11.cpp


$ vim 11.cpp     # append a string "abc" to the file 11.cpp
$ ll -i ./11.cpp
409980 -rw-rw-r-- 2 zyh zyh 508 Dec 22 17:26 ./11.cpp


$ vim 11.cpp     # remove the appended "abc"
$ ll -i ./11.cpp
409980 -rw-rw-r-- 2 zyh zyh 504 Dec 22 17:26 ./11.cpp
Yves
  • 3,291
  • How did you change the file in Vim? Did you add to it or delete from it (could the change be made by only appending to the file or not?) Related: :help backup in Vim, and https://unix.stackexchange.com/questions/36467/why-inode-value-changes-when-we-edit-in-vi-editor – Kusalananda Dec 22 '20 at 07:07
  • @Kusalananda Well, I just do exactly the same modification with hard link and without hard link. After reading :h bakcup, I stil can't figure it out. Don't tell me that creating a hard link will change the strategy of backup of vim... – Yves Dec 22 '20 at 08:47
  • Your file's size is shrinking one byte first, then expanding again, so you're not doing the same modification. – Kusalananda Dec 22 '20 at 08:57
  • @Kusalananda OK, I just reproduced it. – Yves Dec 22 '20 at 09:33

3 Answers3

3

It seems the setting backupcopy is auto (run :set backupcopy? in Vim to confirm).

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

[…]

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.

In case it's not clear: yes (copy and overwrite) does not change the inode number, no (rename and write anew) does change it.

In your case at first auto was like no. After ln ./11.cpp ./xxx Vim noticed there is another link and auto worked like yes.

Kamil Maciorowski
  • 21,864
2

Normally, when you have backups enabled the most efficient approach is to rename the original file and create a new one with the edited changes.

However, when the target file has multiple hard links this isn't the right thing to do, so vim takes the less efficient route of writing a backup file matching the original and then updating the original in-place.

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
2

I reproduced, then thought about what would happen if the inode number changed.

This would indicate that the editor created a new file and removed the old. Probably with some re-naming to reduce the risk of data loss. If it did this for a file with more than one name, then when it removed the old name (the one the file was opened with) the other name would persist, and still point to the old file.

Note: there is no such thing as a hard link. There is only inodes pointing to meta-data and file content. There is also (usually) one or more file names that point to the inode. Each of these names have equal status (nether is a hard-link, they are just names that point to the inode).

ctrl-alt-delor
  • 27,993
  • Hard links don't actually exist, and yet, ln(1) on Linux creates "hard links by default", but can be told to "make symbolic links instead of hard links" instead, and also the link(2) system call can return an error if "the filesystem does not support the creation of hard links". Not just Linux, even FreeBSD ln tells us "there are two types of links; hard links and symbolic links." and FreeBSD link(2) makes "a hard file link". – ilkkachu Dec 22 '20 at 17:15
  • 1
    What I'm saying is that while neither of the names can be said to be "the real file" with the other being "just a (hard) link", the phrase "hard link" is actually a widely accepted for use when a file has multiple names. We just need to remember that both/all the names are equal, and hard links to the actual underlying file. – ilkkachu Dec 22 '20 at 17:16
  • @ilkkachu You are correct about the manuals for ln and link. However to understand them you have to realise that there is no such thing. They create a new name. You could say that a name is a hard-link. So that most files have one hard-link. what is important is to realise that a hard-link is not a different type of think. Therefore the concept of a hard-link as something other than what a normal file has, is what does not exist. – ctrl-alt-delor Dec 22 '20 at 18:07