Prior to this commit, when creating the ControlPath tmp dir for
socket path, Vagrant would simply rely on `rand(1000)` for making unique
dirs for rsyncing files which could result in collisions. This commit
updates that be properly using `Dir.mktmpdir` with a `vagrant-rsync-`
prefix.
As of `net-ssh` version 4.2.0, the key :paranoid has been deprecated in
favor of using :verify_host_key. This commit updates Vagrants ssh config
to use the new key, and deprecates the use of :paranoid.
Prior to this commit, rsync-auto would not properly rsync realtive dirs
outside the cwd if defined in the Vagrantfile. This commit updates that
to ensure that the command looks at the Vagrant config to ensure that
folder was intended to be rsync'd to the machine even if outside the
current working dir.
Prior to this commit, when users invoked the `rsync-auto` command using
the docker provider with boot2docker, vagrant would rsync all known
containers using the boot2docker vm rather than the current working dir.
This commit updates that behavior to ensure that only the current
working dirs vagrant machines will be rsynced.
Windows offers no out-of-the-box rsync utility. By far, the most
commonly used external utilities for Windows rsync are built with the
GNU Cygwin libraries. The cost for this convenience is that rsync on
Windows has to be provided paths that begin “/cygdrive/c” rather than
“c:/“ like other Windows-API utilities. Compounding the situation,
rsync doesn’t create paths/to/sub/targets and so the vagrant plugin
code, when performing an rsync, is responsible for creating
intermediate directories in guest paths if there are any. Furthermore,
the mkdir utility in Windows is not another Cygwin utility like rsync
but the routine mkdir of Windows command.com. Therefore, while rsync
needs the /cygwin paths, mkdir uses the Windows paths. Later, the
chef_solo.rp provisioner running within the guest will expect to find
Windows-style paths in its solo.rb configuration file. Due to all this,
vagrant has to keep track of both the original, possibly dirty Windows
guest path and the cygwin-scrubbed guest path.
Currently, interrupting 'vagrant rsync-auto' once it's waiting for
filesystem events has no effect. Appears to be a deadlock related to
signal handlers in Ruby 2.0 [0].
Remove call to `thread.join` in signal handler. The handler doesn't
need to wait for `true` to be added to the queue; it just needs to
launch the thread.
[0]: https://bugs.ruby-lang.org/issues/7917
Run remote rsync as root to guarantee that rsync can write to guestpath.
This obviates the need to chown the guestpath to the SSH user prior to
sync.
This brings a substantial speedup (2x on a moderately-sized shared
folder) and properly triggers filesystem notifications on only the files
changed by a given sync.