3

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:

Background:

  • 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.

Problem:

  • 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.

Suggestions?

  • The comments were too long I moved them to the chat if you want to continue the discussion. – statox Jul 2 '18 at 7:54
  • 1
    As it's increasingly clear this is more a filesystem issue than a Vim issue (any vim "solution" would be a workaround for the underlying problem) I've asked an updated form of this question here: unix.stackexchange.com/questions/453049/… -- I'll endeavor to copy back any answer I get there, but in the meantime feel free to follow along, you wanderer who comes this way. =) – traeki Jul 2 '18 at 14:58
2

This is something of a "workaround" for my problem, but worth noting, from the Unix afterpost:

add actimeo=0 to the /etc/fstab line for the cfis mount.

This adds some performance overhead for the Samba mount, but seems to eradicate the timestamp jitter that is freaking Vim out. Good enough for now...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.