adrienkohlbecker / vagrant-fsnotify Goto Github PK

Hi, @adrienkohlbecker.

After a few more hours debugging the problem mentioned
here, I still
don't have a solution, but I know a little more about it.

The problem

When running vagrant-fsnotify the user gets the following output:

D, [2015-07-05T17:24:29.520047 #42654] DEBUG -- : Celluloid 0.17.0 is running in BACKPORTED mode. [ http://git.io/vJf3J ]
==> default: fsnotify: Watching /Users/leafac/Documents/code/leafac/vagrant-fsnotify/
D, [2015-07-05T17:24:31.167105 #42654] DEBUG -- : Adapter: considering TCP ...
D, [2015-07-05T17:24:31.167243 #42654] DEBUG -- : Adapter: considering polling ...
D, [2015-07-05T17:24:31.167296 #42654] DEBUG -- : Adapter: considering optimized backend...
/Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/calls.rb:48:in `check': wrong number of arguments (2 for 1) (ArgumentError)
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/calls.rb:26:in `dispatch'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/call/sync.rb:16:in `dispatch'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/cell.rb:50:in `block in dispatch'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/cell.rb:76:in `block in task'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/actor.rb:363:in `block in task'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/task.rb:57:in `block in initialize'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/task/fibered.rb:14:in `block in create'
    from (celluloid):0:in `remote procedure call'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/call/sync.rb:45:in `value'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-0.17.0/lib/celluloid/proxy/sync.rb:40:in `method_missing'
    from /Users/leafac/.vagrant.d/gems/gems/listen-2.8.6/lib/listen/listener.rb:206:in `_init_actors'
    from /Users/leafac/.vagrant.d/gems/gems/listen-2.8.6/lib/listen/listener.rb:87:in `block in <class:Listener>'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-fsm-0.20.0/lib/celluloid/fsm.rb:176:in `instance_eval'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-fsm-0.20.0/lib/celluloid/fsm.rb:176:in `call'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-fsm-0.20.0/lib/celluloid/fsm.rb:129:in `transition_with_callbacks!'
    from /Users/leafac/.vagrant.d/gems/gems/celluloid-fsm-0.20.0/lib/celluloid/fsm.rb:97:in `transition'
    from /Users/leafac/.vagrant.d/gems/gems/listen-2.8.6/lib/listen/listener.rb:100:in `start'
    from /Users/leafac/.vagrant.d/gems/gems/vagrant-fsnotify-0.1.1/lib/vagrant-fsnotify/command-fsnotify.rb:132:in `block in execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/util/busy.rb:19:in `busy'
    from /Users/leafac/.vagrant.d/gems/gems/vagrant-fsnotify-0.1.1/lib/vagrant-fsnotify/command-fsnotify.rb:131:in `execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/cli.rb:42:in `execute'
    from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/environment.rb:301:in `cli'
    from /opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/bin/vagrant:174:in `<main>'

The cause

When the user ran vagrant plugin install vagrant-fsnotify, besides installing
vagrant-fsnotify, Vagrant also installed a new version of Celluloid. Vagrant
comes with Celluloid 0.16.0 and installing the plugin installed Celluloid
0.17.0.

When there's the chance, Vagrant chooses to load the newest version of the
dependency. As you can see from the stacktrace above, the plugin doesn't work
with Celluloid 0.17.0.

Possible explanations

vagrant-fsnotify no longer depends on anything on the .gemspec. It's very
strange that other dependencies are being installed, then.

Under the hood, Vagrant uses Bundler to manage the dependencies, which in turn
depends on RubyGems. It so happens that the new version of Celluloid is not
installed if you do the following:

1. Install vagrant-fsnotify with gem install vagrant-fsnotify.
2. Create a Gemfile with that declares vagrant-fsnotify and run bundle install. Celluloid isn't installed or mentioned on the Gemfile.lock.
3. Build the gem from source by cloning this repository and running gem build vagrant-fsnotify.gemspec; and then installing it with vagrant plugin install vagrant-fsnotify-0.1.1.gem.

I read the relevant part of the Vagrant code that deals with installing plugins
through Bundler. Nothing fancy happens there. They just generate a Gemfile
with the plugins listed.

Testing

Check the ~/.vagrant.d/gems/gems/ folder after installing the
plugin. Celluloid shouldn't be there at all. You can remove the whole
~/.vagrant.d directory to test with a fresh install, if you don't care about
loosing your installed plugins.

The ultimate test

Debugging this was hard, because the problem only happens when installed from
RubyGems. So I decided to rename everything and publish
vagrant-fsnotify-tmp to
RubyGems with gem push vagrant-fsnotify-tmp-0.1.4.gem.

To my surprise, this version of the gem works (!) It doesn't install Celluloid
0.17.0 and the command line tool works. If you want to test yourself, rename the
:fsnotify to :fsnotify_tmp on your Gemfile and run vagrant fsnotify-tmp.

On a related note, merging this
PR was the right
call. Vagrant
documentation says:

Do not depend on Vagrant for your gem. Vagrant is no longer distributed as a
gem, and you can assume that it will always be available when your plugin is
installed.

Finally, the plugin is broken and anyone who installs it needs to get rid of the
whole ~/.vagrant.d directory to restore a working state. This is terrible and
I think we should yank versions 0.1.0 and 0.1.1 from RubyGems until we
figure this out to prevent further damage.

You can do that by running gem yank vagrant-fsnotify -v 0.1.0 && gem yank vagrant-fsnotify -v 0.1.1.

Also, for the next attempt, I suggest we release a beta version first :)

This is one of the weirdest bugs I've ever seen. Any help is much appreciated.

Best.

Would it make sense to turn that 2 second debounce into a config line variable for the Vagrantfile?

Thanks for this great work.

My node server doesn't trigger a rebuild when the touch -a is performed but it does work with touch alone. Is there a reason to use the "-a" option?

Hi @adrienkohlbecker,

I installed the plugin on Windows host as described in README.md. Unfortunately I get the following error when running "vagrant fsnotify":

PS C:\Users\tsotne\Desktop\6.148> vagrant fsnotify
==> default: fsnotify: Watching /c/Users/tsotne/Desktop/6.148/
C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/adapter/config.rb:17:in `realpath': No such file or directory - /c (Errno::ENOENT)
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/adapter/config.rb:17:in `realpath'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/adapter/config.rb:17:in `block in initialize'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/adapter/config.rb:16:in `map'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/adapter/config.rb:16:in `initialize'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/backend.rb:21:in `new'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/backend.rb:21:in `initialize'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/listener.rb:46:in `new'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen/listener.rb:46:in `initialize'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen.rb:36:in `new'
        from C:/Users/tsotne/.vagrant.d/gems/gems/listen-3.0.5/lib/listen.rb:36:in `to'
        from C:/Users/tsotne/.vagrant.d/gems/gems/vagrant-fsnotify-0.2.0/lib/vagrant-fsnotify/command-fsnotify.rb:119:in `execute'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/cli.rb:42:in `execute'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.4/lib/vagrant/environment.rb:301:in `cli'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.7.4/bin/vagrant:174:in `<main>'

It seems as if the plugin is trying to find /c directory, which doesn't exist as the host has Windows installed on it, so the correct path would be C:/

I tried uninstalling and installing the plugin, restarting the VM, but nothing helped. I would appreciate your help.

Thanks.

Hello, my shared folder as to be mount with a custom user and group
The problem is that when a file change is detected. Vagrant is trying to do the touch -am with "vagrant user"
so in the log I can see :
DEBUG ssh: stderr: touch: cannot touch ‘XXXX/manage.py’: Permission denied

Do you see a solution for that ?

Hey!

Guest: Ubuntu 18.10 guest
Host macOS 10.14 (18A391)
Vagrant: 2.2.4
vagrant-fsnotify: 0.3.1

The current behaviour of touch -am results in:

package.json OPEN
package.json ATTRIB
package.json CLOSE_WRITE,CLOSE

With touch -a:

package.json OPEN
package.json ACCESS
package.json CLOSE_WRITE,CLOSE

And touch -m:

package.json OPEN
package.json MODIFY
package.json CLOSE_WRITE,CLOSE

Is this intentional? It seems like touch -m would be the best behaviour to maximise compatibility, no?

(cc @Levon770)

I chanced across this plugin which was linked from an issue on Vagrant's github, and have been trying to get it working in my setup, but to no avail.

Host: OSX 10.13.2 (High Sierra)
Guest: FreeBSD 10.3
Synced folder type: NFS

I'm running a perl Catalyst server on the guest, which reloads automatically when files change, using itnotify where supported or kqueue where not - in our case kqueue which is what FreeBSD provides. I don't really understand the ins and outs of either of these systems, but I mention them in case it matters.

My website filesystem foo lives on my host and is synced to /vagrant/foo via NFS, but no changes to my files in the website seem to trigger the reload system of catalyst (changing the file directly inside the freebsd box does trigger reload as expected)

Is there anything in the above which would cause your plugin to not work? Am I trying to do something fundamentally impossible?

Any help appreciated.

This plugin is not detecting file deletion so when a file is deleted, the plugin touches it also, which is causing the file to be re-created with no content. That's causing issues.

I'm using Vagrant's shared folders.

Vagrant 2.2.5 (x64)
Windows 7 Ultimate 64-bit
VirtualBox 6.0
Powershell 6.2.2

While this is a workable solution, it's still sitting on 100% of a CPU on a mac OSX (10.11.3) host.

Any ideas why this would be the case, or would it be useful for me to trace?

Often when I try to save a "watched" source file in neovim, I get this warning:

WARNING: The file has been changed since reading it!!!

I'm unsure of the exact cause of this bug. However, this behavior seems basically expected:

1. nvim modifies the file
2. vagrant-fsnotify touches the file, setting the modification date past neovim's known file modification date
3. nvim tries to modify the file, but throws a warning because of the modification date difference

And I think it does not occur in a sequence like this:

1. nvim modifies the file
2. vagrant-fsnotify does not touch the file because of a debounce
3. nvim modifies the file

However, I saw the touch command supports the -d parameter:

       -d, --date=STRING
              parse STRING and use it instead of current time

It would be great if we could somehow subtract a second or something from the modification date.

Hi, @adrienkohlbecker.

First of all, thank you very much for creating this tool. It's exactly what I was looking for. I was considering writing something like it myself, so I really appreciate your work.

Is there a reason for vagrant-fsnotify to ignore the added and removed file events?

It seems like added events could be treated the same as changed events, just touch the files.

Removed events could trigger a touch followed by a rm. This is a hack, I admit. But for my applications it would get the job done. I don't think this would be a nice default behavior, but something we could opt in. For example, in the Vagrantfile I could pass in the option fsnotify: :include_removed_events.

I'd be more than happy to send a PR if you think the feature is worth it.

Other than that, the tool is great!

Thanks!

In some cases, the activity that's interesting for fsnotify happens in specific subdirectories. An include regex would support this, and mirror exclude. Linked to #18

In the interim, I am using a fugly regex with negative look-ahead assertions to (ab)use the 'exclude' option to make it work as an 'include'...

When I execute this plugin using the command vagrant fsnotify from a command line, it's working properly, but when I execute it automatically during the VM startup using a trigger in the Vagrantfile as suggested in the readme, it's not working.

I'm executing Vagrant from Powershell.

Vagrant 2.2.5 (x64)
Windows 7 Ultimate 64-bit
VirtualBox 6.0
Powershell 6.2.2

Thank you for continuing to support this plugin, and apologies for my limited understanding of how this works, but I'm unable to get it working with Mac OS Ventura (13.4) and a Debian instance using VMWare. The config is:

    config.vm.synced_folder settings['mount']['www'], "/var/www", type: "nfs", nfs_udp: false, :mount_options => [], fsnotify: true

It says it is watching, and the performance of nestjs seems significantly slower, but no changes are detected. Do you have any suggestions on what I might look at? I've tried the override_guestpath: "/Users/dqj/www", where the folder is mounted.

Here is the debug output of the command installation

vagrant-debug.txt

Is it possible to auto start fsnotify?
This plugin works great. The only thong I miss is auto start. At the moment I have to run manually vagrant fsnotify each time after vagrant up?

vagrant-fsnotify is using 99% of my CPU, is this supposed to happen?

Info
I'm using OSX El Capitan Version 10.11.5

When I run vagrant fsnotify I receive the following output:

rb-fsevent > 0.9.4 no longer supports OS X 10.6 through 10.8.

Please add the following to your Gemfile to avoid polling for changes:
  require 'rbconfig'
  if RbConfig::CONFIG['target_os'] =~ /darwin(1[0-3])/i
    gem 'rb-fsevent', '<= 0.9.4'
  end
[Listen warning]:
  Listen will be polling for changes.Learn more at https://github.com/guard/listen#listen-adapters.
rb-fsevent > 0.9.4 no longer supports OS X 10.6 through 10.8.

Please add the following to your Gemfile to avoid polling for changes:
  require 'rbconfig'
  if RbConfig::CONFIG['target_os'] =~ /darwin(1[0-3])/i
    gem 'rb-fsevent', '<= 0.9.4'
  end

I'm seeing the following when I try to install vagrant-fsnotify:

Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:

An error occurred while installing ruby_dep (1.4.0), and Bundler cannot continue.
Make sure that `gem install ruby_dep -v '1.4.0'` succeeds before bundling.

Warning: this Gemfile contains multiple primary sources. Using `source`
more than once without a block is a security risk, and may result in installing
unexpected gems. To resolve this warning, use a block to indicate which
gems should come from the secondary source. To upgrade this warning to
an error, run `bundle config disable_multisource true`.
Gem::InstallError: ruby_dep requires Ruby version >= 2.2.5, ~> 2.2.

Any ideas? I can't see ruby_dep as a dependency of this plugin, so I'm not sure where that's coming from. Other plugins install fine so I'm not sure if it's something in my version of Vagrant. I'm also a bit puzzled why ruby_dep doesn't see that I'm satisfying its Ruby version requirements! Any help would be very gratefully received!

Hello! I came across this project today. It sounds like it would be very useful for our needs, but also appears to have issues with recent Vagrant versions, as well as having missing features (See #20). Is this project dead? Should it be forked? Is there hope of reviving it?

Hi,

We seem to have a problem detecting large files being moved from a network share mounted on the host system to the shared folder. First we tried using the ATTRIB event to detect a new file arriving in the folder. The file is then moved to a different place for further processing.

Moving small files or moving large files from a folder on the same share as the shared folder seems to work fine, however when a large file is moved from a different share, it is actually copied and since that takes time, our script moves the file before it has finished writing.

Trying to investigate the problem, I noticed that the CREATE event is not fired at all, and strangely enough the CREATE event is actually fired only when deleting the file. The strange thing is that I see that the moved files are being detected as "added" in the output of vagrant fsnotify.

==> default: fsnotify: Added: File_from_host.MOV
==> default: fsnotify: Added: File_from_sshfs.MOV

I am testing on a system with MacOS as host and Ubuntu as guest.
The shared folder is mounted in guest using sshfs:

config.vm.synced_folder "shared", "/home/vagrant/shared", 
    type: "sshfs", 
    sshfs_opts_append: "-o nonempty -o cache=no -o uid=1000 -o gid=1000", 
    fsnotify: true 

The network share which serves as the origin of moved files is also mounted using sshfs.

In vagrant I tried monitoring for changes using inotifywait:

inotifywait --monitor --timefmt '%H:%M:%S' --format '%T %w %e %f' ./shared

Moving file from host to shared folder in Finder (same share, file is moved)

09:46:56 ./shared/ OPEN File_from_host.MOV
09:46:56 ./shared/ ATTRIB File_from_host.MOV
09:46:56 ./shared/ CLOSE_WRITE,CLOSE File_from_host.MOV

Moving file from network share (sshfs) in Finder (progress bar for 5 seconds, file is copied)

09:39:50 ./shared/ OPEN File_from_sshfs.MOV
09:39:50 ./shared/ ATTRIB File_from_sshfs.MOV
09:39:50 ./shared/ CLOSE_WRITE,CLOSE File_from_sshfs.MOV
09:39:55 ./shared/ OPEN File_from_sshfs.MOV
09:39:55 ./shared/ ATTRIB File_from_sshfs.MOV
09:39:55 ./shared/ CLOSE_WRITE,CLOSE File_from_sshfs.MOV

Renaming file in Finder:

10:30:28 ./shared/ OPEN Renamed_File.MOV
10:30:28 ./shared/ ATTRIB Renamed_File.MOV
10:30:28 ./shared/ CLOSE_WRITE,CLOSE Renamed_File.MOV
10:30:28 ./shared/ CREATE File_from_host.MOV
10:30:28 ./shared/ OPEN File_from_host.MOV
10:30:28 ./shared/ ATTRIB File_from_host.MOV
10:30:28 ./shared/ CLOSE_WRITE,CLOSE File_from_host.MOV
10:30:28 ./shared/ DELETE File_from_host.MOV

Deleting file from shared folder using Finder:

09:48:36 ./shared/ CREATE Renamed_File.MOV
09:48:36 ./shared/ OPEN Renamed_File.MOV
09:48:36 ./shared/ ATTRIB Renamed_File.MOV
09:48:36 ./shared/ CLOSE_WRITE,CLOSE Renamed_File.MOV
09:48:37 ./shared/ DELETE Renamed_File.MOV

Any other ideas on how to reliably detect a completed movement/copying process of a file would be most welcome!
Thanks in advance!

Sorry, wrong repo.

The vagrant-fsnotify not working properly with vagrant version 2.4.4. the plugin see the changes on windows 10 host, but not provide the changes to guest virtual machine (ubuntu 18.04), where I am running angular. before vagrant version update it works perfectly. is there any known issues and solutions

Currently, the exclude regexes are mangled, in order to support shell-style '*' and '**' input.

Perhaps an exclude_regex parameter can be added, with no mangling step?