Apparent NFS issue

[bikingcoder]

Hi, I'm having trouble editing files over NFS. Specifically I get the error: File modified by an external process, use :w! to overwrite when attempting to write a file for the second time.

This seems to be the same on NFS V3/4.

The NFS client is a VirtualBox machine, that is mounted using Vagrant, although this should probably be irrelevant. The guest OS is FreeBSD, which might be relevant.

Editing files outside the NFS mount is non-problematic.

Just wondering if there is some kind of known issue. I'm guessing it's in relation to the inotify library - is there anyway to override this file change detection?

Thanks for what looks likes a promising editor.

[pascalkuthe]

we use mtime to detect if a file is changed. Almost every os should have some reasonable notion of mtie. There are some tricks to check if the fs supports mtime (used by git/gitoxide). I guess we could implement some autodection but it seems like a pretty niche usecase

[the-mikedavis]

IIRC I ran into something like this a long time ago with a Vagrant setup that synced files between the host and VM. The issue was the VM's clock was way behind the host. You may be able to solve it by syncing the VM's clock, for example with ntpdate (though I believe ntpdate is deprecated these days).

[bikingcoder]

@pascalkuthe Thanks, you pointed me in the right direction. And @the-mikedavis you were correct, although I spotted it myself on closer inspection of the modified time stamps. My guest FreeBSD OS wasn't respecting daylight savings. Thanks!

(it's also imperative to have ntpd service running!)

[bikingcoder]

I'm going to reopen this, because it's still a sporadic issue, even with NTP setup. And using the editor on an NFS share doesn't seem such an esoteric use case - to me at least.
If Helix is comparing some internally held modified time with the last modified timestamp of the file, it would be interesting to know at exactly what point this internally held modified time is stored. I'm presuming the sporadic nature is something to do with the round trip to the NFS server, but need to investigate more.
It is also quite easy to miss the red warning text that briefly flashes up, which can lead to frustration.

[bikingcoder]

Even with NTP setup this is a deal breaker on NFS. I wonder if the tolerance in the time comparison could be configurable at least or adjusted?

[bikingcoder]

I've found out that Virtualbox has its own time sync service, and it seems this might have been an issue since it seems more stable now (of course no need to have to have this running in tandem with NTP). It can be disabled by adding the --disable-timesync flag to the vboxservice service. (for FreeBSD that is in usr/local/etc/rc.d/vboxservice).