Vagrant: rsync-auto no longer syncs subdirectories or directories outside of the cwd

[LukeCarrier]

Vagrant version

1.9.7

Host operating system

$ uname -a
Linux HLC000897 4.10.0-26-generic #30-Ubuntu SMP Tue Jun 27 09:30:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.04
DISTRIB_CODENAME=zesty
DISTRIB_DESCRIPTION="Ubuntu 17.04"
NAME="Ubuntu"
VERSION="17.04 (Zesty Zapus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 17.04"
VERSION_ID="17.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=zesty
UBUNTU_CODENAME=zesty

Guest operating system

ubuntu/xenial

Vagrantfile

Please see a minimal repro example with directories here:
https://github.com/LukeCarrier/vagrant-rsync-auto-bug

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/xenial64"

  config.vm.synced_folder ".", "/vagrant", type: "rsync"
  config.vm.synced_folder "./insider", "/insider", type: "rsync"
  config.vm.synced_folder "../outsider", "/outsider", type: "rsync"
  config.vm.provision "delete-all-the-things", type: "shell", inline: "rm -f /{vagrant,insider,outsider}/README.md"
end

Debug output

Please see console output here:
https://github.com/LukeCarrier/vagrant-rsync-auto-bug

Expected behavior

rsync synced folders that are either subdirectories of the Vagrant CWD or exist outside of the directory structure should be synced to the guest with both rsync and rsync-auto.

Actual behavior

vagrant rsync syncs the files. vagrant rsync-auto does not.

Steps to reproduce

Clone the repro case:

$ git clone https://github.com/LukeCarrier/vagrant-rsync-auto-bug.git
$ cd vagrant-rsync-auto-bug

Bring up the machine, preventing the provisioner from removing the README files:

$ cd _vagrant/
$ vagrant up --no-provision

See that the three READMEs are present:

$ vagrant ssh -c "ls -1 /{vagrant,insider,outsider}/README.md"
/insider/README.md
/outsider/README.md
/vagrant/README.md
Connection to 127.0.0.1 closed.

Let the provisioner remove the READMEs and verify:

$ vagrant provision
$ vagrant ssh -c "ls -1 /{vagrant,insider,outsider}/README.md"
ls: cannot access '/vagrant/README.md': No such file or directory
ls: cannot access '/insider/README.md': No such file or directory
ls: cannot access '/outsider/README.md': No such file or directory
Connection to 127.0.0.1 closed

Run rsync-auto and note the output indicating that the directories are being excluded:

$ vagrant rsync-auto
==> default: Not syncing /home/[email protected]/vagrantbug/_vagrant/insider as it is not part of the current working directory.
==> default: Not syncing /home/[email protected]/vagrantbug/outsider as it is not part of the current working directory.
==> default: Doing an initial rsync...
==> default: Rsyncing folder: /home/[email protected]/vagrantbug/_vagrant/ => /vagrant
==> default: Watching: /home/[email protected]/vagrantbug/_vagrant
^C

Finally, note that the files are no longer present on the server:

$ vagrant ssh -c "ls -1 /{vagrant,insider,outsider}/README.md"
ls: cannot access '/insider/README.md': No such file or directory
ls: cannot access '/outsider/README.md': No such file or directory
/vagrant/README.md
Connection to 127.0.0.1 closed.

References

• GH-5160
• GH-8756

[disastrous-charly]

Same issue with vagrant 1.9.7 and fedora 25.

rsync-auto output :
==> install: Not syncing /whatever/result-processor/project as it is not part of the current working directory. ==> install: Doing an initial rsync... There are no paths to watch! This is either because you have no synced folders using rsync, or any rsync synced folders you have have specifiedrsync_autoto be false.

Working directory is /whatever/
vagrant rsync doesn't produce error.

Any news ?

[disastrous-charly]

Well... going to Fedora 26 and downgrading to vagrant 1.9.1 fix the error for me !

[LukeCarrier]

@disastrous-charly all versions <= 1.9.6 should be good to go. The change was definitely introduced in 1.9.7. You can also revert the change against 1.9.7.

[LukeCarrier]

@briancain thanks for addressing this -- much appreciated.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.