Mount resource does not support spaces in Windows mount points

[charlesjohnson]

Consider:

mount 't:'
  source '\\\\server\\aPathWithoutSpaces\\a path with spaces'
  action :mount
end

This resource will fail with 'ArgumentError: The network location cannot be reached.'

On the other hand, this will work:

mount 't:'
  source '\\\\server\\aPathWithoutSpaces'
  action :mount
end

[lamont-granquist]

We'll need the full backtrace

[adamedx]

I'm looking at it and will update -- turns out it may not be spaces, but the fact that we were traversing a reparse point on DFS share, and the permissions were... odd. If you mount the drive to a drive letter, you can't get list files permission on some directories (even with cmd.exe / powershell, no ruby involved).

[smurawski]

Windows team (@btm @jdmundrawala @ksubrama) - is this on the backlog? @charlesjohnson is this a blocker or just a bug you tracked down?

[jaym]

Have not seen it on our backlog

[charlesjohnson]

As this was several months ago I don't recall vividly, but it was a "bug we encountered while team programming at MS with a customer and @adamedx." I think @adamedx 's update is correct, in that it was a reparse point on the DFS share with odd permissions, but it would need further clarification. It's possible both odd permissions from reparse AND spaces were an issue.

[adamedx]

Yeah, I think we can just warn and doc -- the equivalent shell command of ls \\server\apathwithoutspaces also failed. Having a UNC path with more than two components (i.e. \server\share) was actually a new addition in Windows 2000 (not supported prior to that). I'm guessing there are some strange things with inheritance of permissions if you go beyond that. Given that the scenario doesn't work with native API's and tools, I think we should help users be successful -- give a warning to mount just at the level of \\server\share, or maybe only show the warning if we actually fail, i.e. a specialized error message. Should be easy enough to unit test. Feel free to add to the backlog.

[thommay]

This is expected behaviour on Windows, so there's not an awful lot we can do here.