Detecting modifications as additions in docker w/ osxfs mounted volume

[jayniz]

I'm editing my files using vim on OSX. Guard is running inside a docker container with my local (host) source directory mounted into the container.

Problem: Editing files with vim doesn't trigger modification events but addition events. Editing with other editors (e.g. atom) does.

So inside the container, I checked what happens by watching the output of inotifywait -m -r . when opening test.txt with vim, adding a space and saving it:

./ CREATE 4913
./ ATTRIB 4913
./ DELETE 4913
./ CREATE test.txt
./ ATTRIB test.txt
./ MODIFY test.txt
./ MODIFY test.txt
./ DELETE test.txt~
./ DELETE test.txt~
./ CREATE test.txt
./ ATTRIB test.txt
./ MODIFY test.txt
./ MODIFY test.txt

I see some stuff I don't (want to) understand (a file called 4913, multiple deletes on the swap files, multiple modifies on test.txt).

Now, let's open the file in atom, add a space and save it:

./ CREATE test.txt
./ ATTRIB test.txt
./ MODIFY test.txt
./ MODIFY test.txt

It seems like the MODIFY event is making it into the container in both cases, however listen doesn't seem to pick it up. So inside the container, I ran this snippet from the troubleshooting docs and did the same "edit in vim, edit in atom" cycle:

require 'bundler'
require 'listen'
listener = Listen.to('/home/app/rails') do |modified, added, removed|
  puts "modified absolute path: #{modified}"
  puts "added absolute path: #{added}"
  puts "removed absolute path: #{removed}"
end
listener.start
sleep

Editing the file in vim, adding a space and saving yields:

modified absolute path: []
added absolute path: ["/home/app/rails/test.txt"]
removed absolute path: []
modified absolute path: []
added absolute path: ["/home/app/rails/test.txt"]
removed absolute path: []

Editing the file in atom and saving yields:

modified absolute path: ["/home/app/rails/test.txt"]
added absolute path: []
removed absolute path: []

The fact that with inotifywait -m -r . I saw the MODIFY test.txt but at the same time with listen I saw an addition of test.txt makes me think that this might be a bug in listen, then again I don't really know what I'm talking about (i.e. why would there be two MODIFY (or from listen's point of view two addeds) when I just save the file once)?

I came across this when noticing that guard-rspec doesn't notice any of my edited files, but other guards like guard-bundler did. But I am assuming, that any guard that's listening to modifications (and not additions) is probably broken in many docker based development workflows that involve running things with guard inside docker on osx.

P.S.

• I don't think this is a symlink issue
• For what it's worth, here is the docker's information on file system events in osxfs

P.P.S.

Versions:

• Ubuntu 16.04 LTS docker image
• ruby 2.3
• listen 3.1.5
• rb-fsevent-0.9.8
• rb-inotify-0.9.7
• ffi-1.9.14

[mbriggs]

for folks looking for a guard-rspec temporary workaround, using this monkey patch from guard/guard-rspec#391 worked for me

class Guard::RSpec
  def run_on_additions(paths)
    return false if paths.empty?
    _throw_if_failed { runner.run(paths) }
  end
end

[a2ikm]

#434 says set backupcopy=yes is a workaround, and it works for me 😄

[idoa01]

Had a difficult time finding a way to monkey patch Guard::RSpec as the method @mbriggs suggested didn't work for me, I ended up with an empty Guard module, but I finally found a way to do so:

Guardfile:

guard :rpsec, cmd: "bundle exec rspec" do
  Guard::RSpec.class_eval { alias_method :run_on_additions, :run_on_modifications }

  ...
end

[ColinDKelley]

We recently changed Listen to listen to all the major file events. (Previously it was omitting some that can cause duplicates...but that was no longer necessary since Listen now has a "debounce" layer that catches and suppresses duplicate events.

I'm hoping the above addressed this issue, so I'm going to close it.