fs_watch causes mtime to be (re)set on sync

[mblarsen]

From slack:

@mblarsen

Having a (non-)nanbox issue. I have file watching set up (fs_watch) which works great. But I'm getting a lot of warnings from my editor (vim) that the file has been changed since I last read it after I save the first time. Has anyone run into this issue and know how to resolve it?

@tylerflint

I think we may end up having to patch the kernel to include a custom syscall for nanobox

essentially what happens, is that when a file changes on the host (your workstation) we relay an event into the nanobox container. At that point, the only way to inform the linux kernel that the file was changed, is to issue a touch on the file, which triggers the event to any process watching for changes...

in turn, issuing the touch will update the mtime and push that back into the host.

it's a really hard problem that we've tried a bunch of times to solve.

I think we'll just end up writing a custom syscall and an accompanying user process to trigger it.

[glinton]

@mblarsen Can you list steps to reproduce, as well as the contents of nanobox config ls and what OS you're using? I've been unable to duplicate this issue as described. TIA.

[mblarsen]

@glinton sorry for the very late reply.

I've recorded this short video showing the issue https://www.dropbox.com/s/20kwxkrm53u54v4/nanobox-mac-save.mp4?dl=0

In the video I have vim running on the left. On the right I run nanobox run and then start yarn watch to watch my resources and rebuild upon change.

I then go to vim to make change. After the first save I save again without making changes and I get the warning that the file on disk is newer than the one in my editor.

{
  "provider": "docker-machine",
  "ci-mode": false,
  "ci-sync-verbose": false,
  "mount-type": "native",
  "netfs-mount-opts": "",
  "cpus": 4,
  "ram": 4,
  "disk": 102400,
  "external-network-space": "192.168.99.50/24",
  "docker-machine-network-space": "172.21.0.1/16",
  "native-network-space": "172.20.0.1/16",
  "ssh-key": "default",
  "ssh-encrypted-keys": false,
  "anonymous": false,
  "lock-port": 12345
}

I'm running on High Sierra now, but the issue is the same.

[mblarsen]

@glinton were you able to see the problem from the video?