Błędne zdarzenia związane z udostępnianiem folderów i plików

Mam maszynę wirtualną Ubuntu, do której uzyskuję dostęp za pośrednictwem Vagrant. Na moim hoście (Mac OSX) znajduje się folder z kilkoma plikami, które udostępniam maszynie wirtualnej. Na tej maszynie wirtualnej chcę użyć wartownika, aby obserwować zmiany plików i wykonać pewne czynności, jeśli którykolwiek z tych plików się zmieni.

Ustawiłem poprawnie straż, a kiedy zmieniam udostępniony plik z maszyny wirtualnej, działa dobrze i uruchamia odpowiednie skrypty. Ale jeśli spróbuję zmienić udostępniony plik z mojego komputera hosta, to zdarzenie zmiany pliku nie propaguje się, a straż nie reaguje.

Tak wygląda mój włóczęga udostępniony folder (całkiem zwyczajne rzeczy)

local_config.vm.share_folder "app", "/var/www/app/current", "../app"

Próbowałem nawet używać NFS sharing ( :nfs => true), ale to nie pomogło.

Czy jest jakiś sposób, aby zdarzenia zmian plików były propagowane z hosta na maszynę wirtualną? Czy jest to coś z natury Vagrant / VirtualBox?

AKTUALIZACJA:

Po kilku próbach zainstalowałem klejnot ZenTest , który zawiera narzędzie autotestu, umożliwiające podobną funkcjonalność dotyczącą zdarzeń zmiany plików.

Po uruchomieniu autotestu na maszynie wirtualnej i zmianie plików z mojego hosta zmiany te są propagowane i autotest reaguje .

Na tej podstawie wydaje się, że propagacja zdarzeń zmiany pliku jest kwestią ochrony, a nie włóczęgi lub wirtualnego pudełka.

Nie analizowałem jednak różnic w implementacji między ochroną a autotestem.

Teraz wiem, że można wychwycić zdarzenia zmiany pliku z hosta na maszynie wirtualnej. Czy ktoś ma jakiś pomysł, jak to osiągnąć za pomocą wartownika? Bardziej lubię strzec ze względu na DSL i ogólną użyteczność.

Główną przyczyną jest to, że VirtualBox nie kaskaduje zdarzeń zmiany pliku na hoście na maszynie wirtualnej. Guard (w systemie Linux) oczekuje na otrzymywanie powiadomień za pośrednictwem zdarzeń inotify. Zamiast tego możesz przeprowadzić ankietę ochronną dotyczącą zdarzeń guard -p, ale może to doprowadzić do maksymalnego wyczerpania się procesora, dzięki czemu możesz z powrotem ograniczyć odpytywanie guard -p -l 10.

Od guard help start:

  -l, [--latency=Overwrite Listen's default latency]
  -p, [--force-polling=Force usage of the Listen polling listener]

http://www.softr.li/blog/2012/07/21/running-guard-over-vagrant

Wiem, że to starsze pytanie, ale tutaj jest bardziej aktualna odpowiedź:

Straż -o/--listen-ondokumentacja opcja

Wklejono tutaj w celu szybkiego odniesienia:

-o/--listen-on option

Use Listen's network functionality to receive file change events from the
network. This is most useful for virtual machines (e.g. Vagrant) which have
problems firing native filesystem events on the guest OS.

Suggested use:

On the host OS, you need to listen to filesystem events and forward them to
your VM using the listen script:

    $ listen -f 127.0.0.1:4000

Remember to configure your VM to forward the appropriate ports, e.g.
in Vagrantfile:

    config.vm.network :forwarded_port, guest: 4000, host: 4000

Then, on your guest OS, listen to the network events but ensure you
specify the host path:

    $ bundle exec guard -o '10.0.2.2:4000' -w '/projects/myproject'

Jeśli ktoś napotka ten problem, a ochrona nadal nie działa ...

Skończyło się na watchr . Jest to alternatywa dla straży. Propagacja zdarzeń z hosta na maszynę gościa działa poprawnie w watchr. Jest także bardziej elastyczny niż autotest.