It has nothing to do with your system specs or bandwidth.
UNC paths do not denote the protocol, so Windows attempts to connect through several protocols it knows. On most systems it uses SMB and WebDAV in that order.1
live.sysinternals.com is a HTTP/WebDAV server and doesn't speak SMB, but worse than that, it doesn't even respond to attempts to make an SMB connection.2 When Windows attempts to connect first on TCP port 445 (modern SMB) and then port 139 (NetBIOS), it doesn't even receive a refusal – it just sits there waiting until the timeout counts down.
Several seconds later, the Windows network client gives up with SMB and attempts WebDAV (over port 80), which succeeds but by now the delay has occured. And if you access the server directly through a UNC path (not a mapped drive letter), this procedure likely repeats for every file operation as Windows doesn't seem to remember the server's type for long and just keeps retrying SMB again.
And there's also the issue that 1) the server may be physically far away from you, adding latency even to successful requests; 2) WebDAV itself is a verbose XML-based protocol with no batching. Both contribute to the total latency.
1 (Historically, when Windows started using UNC paths, there were many LAN protocol suites. A short non-DNS name like \\mypc
could have meant SMB/NetBIOS in no less than three different ways – over IPv4 or IPX or NBFrames – but it could also have been NetWare NCP, or AppleTalk AFP, or possibly VINES and DECnet and other weird stuff.)
2 (Actually, even if the server was correctly configured to immediately refuse connections to unsupported ports, there would be another problem: some ISPs block connections to SMB-related ports, to reduce the potential for malware spread.)
net use S: \\live.sysinternals.com@80\tools
Do you find that more responsive?S:/
, no less), so I don't think that helps. But I just noticed you have the port number defined, so let me try that. Also, I just got a weird error right now trying to access it (configured as I had it before): screenshotcmd
format, and refreshedexplorer.exe
. It was able to load without any error (which was kind of weird, I'd never seen that before) and while it wasn't exactly quick per-se — I ranautoruns64.exe
, which is only 856KB in size — I do want to say it was much quicker than before, and there wasn't any longer periods of hanging where it felt like something was timing out before it'd finish loading. I'm a litle concerned about about observation bias or other uncertainties still, but can you explain what the difference was in