3

[I originally posted about this on the vi/vim stackexchange, but it's increasingly clear that the core issue is more the filesystem than the editor that's complaining about it]

TL;DR -- Files on a CIFS mount are "changing" in the background in a way that alarms Vim when I try to write to them. I need help either calming Vim or removing the underlying "modification" noise.

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 standard Windows 10 sharing, and mounted on the Linux guest as a cifs drive in /etc/fstab.
  • I'm editing files from the Guest system using vim 8.1.

Problem:

  • Most of the time (apparently at random) I try to :write a file I'm editing in vim, I get
WARNING: The file has been changed since reading it!!!
  • I know the contents have not changed on disk between the two writes.

I want to prevent the bogus warning, and also to better understand how to examine its provenance.

Basically, immediately after I write a file to disk, something is making a triggering modification to the file. I suspect the Samba infrastructure, but I'm not sure how to pin this down. I've looked at strace logs, but I'm not super skilled at making sense of that data.

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?

  • How is the Windows share mounted? Smbfs or cifs? – AlexP Jul 2 '18 at 16:19
  • @AlexP cifs -- here's the /etc/fstab line: //10.0.2.2/netgd /home/jsh/gd cifs credentials=/home/jsh/.smbcredentials,defaults,uid=1000,gid=1000,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.mount-timeout=1 – traeki Jul 2 '18 at 18:01
  • This answer (on AskUbuntu) suggests actimeo=0 as a possible solution to the problem of the client and server having a different idea of a file's last modified time. (The option actimeo=0 suppresses caching file metadata such as timestamps.) Note that this will make the SMB protocol somehow even more chatty than it already is. – AlexP Jul 2 '18 at 21:09
  • It feels a little more like a "workaround" than a "fix" at some level, since it does slow disk performance perceptibly. But that's WAAAY more tolerable than having to confirm every time I hit :w in vim, which is like 100x/hour. I'd love to get a better handle on why the cifs system is misbehaving and fix that directly, if other folks have insight in that direction, but thank you SO MUCH for a solution to the symptom, @AlexP. HUGE relief. – traeki Jul 2 '18 at 21:31
  • As for the root cause, the documentation of Samba speaks about Windows being somewhat lazy with updating the last modified time of files... – AlexP Jul 2 '18 at 23:15
1

I would suggest turning off the Windows automatic disk optimizer for that disk. Linux looks at the location on disk as it is journaling, Windows does not. So even if it changes location by a little bit, to Linux it is not the same anymore.

That should solve your problem!

https://www.top-password.com/blog/disable-automatic-drive-optimization-defrag-in-windows-10/

  • While this sounds like a decent hypothesis, do you have any reason to be particularly confident that this is the issue? This potential solution has some downsides that would be good to avoid if there are other options. – Catskul Nov 29 '18 at 18:51
  • I was having roughly that same problem but was not NTFS, doing this stoped the issue. As I said I was not using NTFS, milage may vary. – Michael Prokopec Dec 1 '18 at 21:43

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.