@khoamisfit : I still confusing about the effected of permission mode on file. But Im think im closely to figure out why. Let me explain more :
Most of filesystem does not provide any kind of synchronization among I/O operations issued by the process on the same file, but as I remember there are system calls such as flock() are available to allow process to synchronize themselves on the entire of file or piece of it. So here is what Im trying to imagine, when you mount a file on docker host to container with mode 644, and try to append new content to it, it changed on both side, at this state, if you check stat on both side, the inode number is not change, but after that, if you use vim insert mode to modify the file on docker host, the file will not change on container, at this state if you try to compare inode again, the inode of the file on the docker host changed, but on the container, it stay the same. Then if you try to change the file permission to 664 (rw-rw-r) it synced on both. So let go back to what I describe aboved, if the file mode is 664 or group/other have permission to rw, the inode number will not change when you modify a file, and it synced to both side.
The set backupcopy=yes will force vim to reuse existing inode number instead of create new one.
I hope you get my idea right? inode not change --> file synced | inode changed --> file not synced
This might be involved into how linux handle file and depends on per filesystem.
When ever a process modifying a file, which will involve a system call mmap ( find out more with man mmap)
man mmap
mmap() creates a new mapping in the virtual address space of the calling process. The starting address for the new mapping is specified
in addr. The length argument specifies the length of the mapping.
If addr is NULL, then the kernel chooses the address at which to create the mapping; this is the most portable method of creating a new
mapping. If addr is not NULL, then the kernel takes it as a hint about where to place the mapping; on Linux, the mapping will be created
at a nearby page boundary. The address of the new mapping is returned as the result of the call.
The contents of a file mapping (as opposed to an anonymous mapping; see MAP_ANONYMOUS below), are initialized using length bytes starting
at offset offset in the file (or other object) referred to by the file descriptor fd. offset must be a multiple of the page size as
returned by sysconf(_SC_PAGE_SIZE).
You can use strace to dig more on each state of file mode, I did some strace to debug but forgot to save some of it to put it here so we can easy to compare, but ideally, whenever inode not change, the mapping address are the same, if inode changes, the mapping address also change.
When a process read a file its first look in the file descriptor ( fd contain all the informations of a file, included inode, check more on http://www.bottomupcs.com/file_descriptors.html ). So I guess when the inode on docker host change, the mapping address also change, but on the container is not, so it still point to the old version object mapped of the file. Will try to dig deeper
But still, I wont get why file permission effected to this. Maybe someone with more experiences on linux can explain.