Escape backward slashes in synced folder id

[legal90]

That fixes invalid share names in Windows guests, where backward slash
character is used as a path separator.

Details:
Currently, if we define the synced folder this way (for Windows guest):

config.vm.synced_folder "../", 'C:\Users\vagrant\my_share'

then the share id will be this string: 'C_\Users\vagrant\my_share'
In the guest it will be exposed as \\psf\C_Usersvagrantmy_share - Parallels Desktop tries to replace backslashes with some special character by itself. Meanwhile the Vagrant expects that the
share is available at \\psf\C_Usersvagrantmy_share, so it creates a broken symlink.

This Pull-Request adds \ to the regex, so this char will be replaced with _.
The result share name will be 'C__Users_vagrant_my_share' and it will be available at \\psf\C__Users_vagrant_my_share without any issues.

The similar PR has been sent to VirtualBox provider: hashicorp/vagrant#8433

[romankulikov]

Two points from my side:

• Why does Vagrant expects path \\psf\C_Usersvagrantmy_share (without special Unicode symbols)? May be this the issue in Vagrant?
• Parallels Desktop also remaps other symbols: ", *, :, <, >, ?, | – may they should be handled as well?

[legal90]

• Parallels Desktop also remaps other symbols: ", *, :, <, >, ?, | – may they should be handled as well?

Yes, good point! Currently we handle only : and / here. I'll add other characters too.

• Why does Vagrant expects path \\psf\C_Usersvagrantmy_share (without special Unicode symbols)? May be this the issue in Vagrant?

At the early stage, before booting the VM, our provider configures the VM by setting the list of shared folders. It calls driver method #share_folders, which actually doesprlctl set <vm_uuid> --shf-host-add <share_name> --path <host_path>. For <share_name> it uses the value of :name param if it is set explicitly in Vagrantfile. Otherwise the guest's path will be used.
Before putting the share name to the CLI call, our provider replaces special characters there:

vagrant-parallels/lib/vagrant-parallels/synced_folder.rb

Line 22 in 4025015

name: os_friendly_id(id),

After the VM boot Then right before mounting shared folders in the guest, provider determines the share name from the output of drivers method #read_shared_folder, e.q. from the output of prlctl list -i <vm_uuid> --json:

vagrant-parallels/lib/vagrant-parallels/synced_folder.rb

Line 55 in 4025015

id = shf_config.key(data[:hostpath])

In our example prlctl returns the following:

...
			"C_\Users\vagrant\my_share": {
				"enabled": true,
				"path": "\/Users\/legal\/Documents",
				"mode": "rw"
			},
...

Since backslashes are not escaped in the output (which looks like a bug of prlctl, BTW), the key is decoded exactly as a string 'C_Usersvagrantmy_share'.
So, the expected share name is already "broken" at this point.
But on the other hand, there is an internal remapping made by Parallels Desktop in Windows guest (it becomes 'C_Usersvagrantmy_share') and Vagrant knows nothing about that.
So here we should just avoid all cases when the actual share name is different from the expected one.

[legal90]

I've updated PR by adding more characters to the escaping regex.
Also I've updated my previous comment: shared folders configuring and mounting happens subsequently, after the VM boot.

[romankulikov]

Ok. Thanks for detailed explanation!