I have really two questions, sides of the same coin:
1) How exactly does vim evaluate whether the buffer is different from a file in order to determine the error
WARNING: The file has been changed since reading it!!!
...and how can I replicate that test to get a clearer sense of what aspect of the file is causing the perceived change?
2) How can I prevent these warnings when the file content is not what has changed? Is this a Bad Idea for reasons I'm missing?
LONGER FORM EXPLANATION:
- I have a Linux Guest virtual machine (Arch/Manjaro-i3 64-bit) running on VirtualBox under a Windows 10 Host machine.
- The host machine has a partition formatted as NTFS that is intended to be shared between the two.
- The shared partition is shared via Samba (standard Windows 10 sharing), and mounted on the Linux guest as a cifs drive in /etc/fstab.
- The shared partition is populated and monitored by Google Backup & Sync.
- I'm editing files in that mount, using vim 8.1 on the Guest system.
- I get the aforementioned error the second time I try to write to a file in a given session.
- re-editing the file after each write (':e') prevents the warning
- That's not a viable workaround. It's annoying, but more importantly it wipes my undo history every time I save my work.
- I know the contents have not changed on disk between the two writes.
So, I want to prevent the error, and also to understand how to examine its provenance.
Basically, immediately after I write a file to disk, something (Samba, Google Drive, or something else) is making a triggering modification to the file.
I suspect the issue is some latency between when vim thinks it timestamped the file, and what timestamp gets recorded by Samba when it eventually sees the write-op, such that vim thinks it might be out of date.
But I'm not sure... And if that's true, I'm still not savvy enough to fix it.