Using Directory.Exists on a network path can take almost half a minute to return `false`

JTinkers

New member
Joined
Jul 29, 2025
Messages
3
Programming Experience
5-10
Hey there,
I come with a very simple yet intriguing issue and I was wondering if anyone else found a solution to it.

I have the following environment:
- a working server
- a working and shared network drive
- a simple app that uses the network path (via Directory.Exists)

What I've noticed is, when the server is OK, but for some reason the path IS NOT - the `Directory.Exists` method is going to take an awful long time to return `false`.
This is likely due to internals waiting for network to eventually time out, and since this method is called every HTTP request is received - it's delaying all responses by that much (usually 30s).

I've prepared a small repro code, just bear in mind you would need to at least setup a local shared folder:

C#:
Expand Collapse Copy
using System.Diagnostics;
using System.Net.NetworkInformation;

namespace TestNetworkPathsQuick
{
    internal class Program
    {
        static void Main(string[] args)
        {
            CheckPath(@"\\192.168.1.10\test"); // few ms, happy path
            CheckPath(@"\\192.168.1.11\test"); // few ms
            CheckPath(@"\\192.168.1.10\wrong"); // 8-30 seconds
        }

        static void CheckPath(string uncPath)
        {
            Stopwatch sw = Stopwatch.StartNew();

            string server = GetServerFromUncPath(uncPath);
            bool exists;

            if (PingHost(server))
            {
                exists = Directory.Exists(uncPath);
            }
            else
            {
                exists = false;
                Console.WriteLine($"Server {server} unreachable. Skipping Directory.Exists");
            }

            sw.Stop();
            Console.WriteLine($"Dir exists: {uncPath} - {exists}, elapsed: {sw.Elapsed}");
        }

        static string GetServerFromUncPath(string uncPath)
        {
            if (uncPath.StartsWith(@"\\"))
            {
                var parts = uncPath.Substring(2).Split('\\');
                if (parts.Length > 0)
                    return parts[0];
            }
            return string.Empty;
        }

        static bool PingHost(string host)
        {
            try
            {
                using var ping = new Ping();
                var reply = ping.Send(host, 1000); // 1 second timeout

                return reply.Status == IPStatus.Success;
            }
            catch
            {
                return false;
            }
        }
    }
}
 
And there is not much you can do about it, unless you try to use some of the async versions to access the paths by passing in a cancellation token that has a timeout.

You are doing the right thing by trying to pre-flight the access by pinging the server to see if it even exists. In your shoes, I would add some caching, where if a pre-flight check finds that the server doesn't exist, then remember that fact for the next 5 or 10 minutes, and then try again on the next request. Yes, someone will still suffer a wait, but not everybody will suffer.

An alternative is to use Polly to do retries.

Another alternative is combine the pre-flight checks, and Polly.
 
*** removed unnecessary quote ***

Yeah, I think this will likely end up being a service with exposed HTTP endpoint on the target server (the one where the network drive is at).
I was hoping there was other way to poll for it, but I guess we have to heavily rely on Windows internals and how they handle UNC.
 
Last edited by a moderator:
That's a good alternative as well to host a web service on the other machines with the file shares. Strange though that you are getting slow connection that way. In my experience, the slow network shares are trying to connect to dedicated network file storage devices and Macs.
 
Back
Top Bottom