Why Your Windows Paths Break Inside a Docker Container (a...

If you have ever deployed a .NET app inside a Docker container on a Windows host, you have probably run into a situation where a path that looks perfectly valid on the host machine causes subtle, hard-to-debug failures inside the container. This post walks through the exact problem, the runtime behaviour that causes it, and a one-line fix.

The Setup

I was building DevMetrics, a self-hosted developer productivity dashboard. Users add local Git repositories through a web form by pasting in the path. The app then calls LibGit2Sharp to scan commits from that path.

On Windows, running via dotnet run, everything worked fine. After dockerizing the app and running it as a Linux container, paths started silently mangling themselves.

The Symptom

A user pastes this into the form:

D:\Users\Downloads\my-project

The app logs show the path it actually tried to open:

/app/D:\Users\Downloads\my-project

The working directory /app had been prepended to the Windows path. LibGit2Sharp then throws because that path obviously does not exist.

Why It Happens

The culprit is Path.GetFullPath. In .NET, calling GetFullPath on a relative path resolves it against the current working directory. The relevant question is: what counts as "rooted" on Linux?

// On Windows: returns true
Path.IsPathRooted("D:\\Users\\Downloads\\my-project");

// On Linux: returns FALSE
Path.IsPathRooted("D:\\Users\\Downloads\\my-project");

Linux has no concept of Windows drive letters. To the Linux runtime, D:\Users\Downloads\my-project is not an absolute path starting with a drive letter. It is a relative path that happens to start with the character D.

So when you call:

Path.GetFullPath("D:\\Users\\Downloads\\my-project")

on Linux, the runtime treats it as relative and prepends the process working directory, giving you /app/D:\Users\Downloads\my-project.

No exception is thrown. No warning is logged. The path just silently becomes wrong.

The Fix

Guard with IsPathRooted before calling GetFullPath:

private static string NormalisePath(string path)
{
    var trimmed = path.Trim();

    var absolute = Path.IsPathRooted(trimmed)
        ? trimmed
        : Path.GetFullPath(trimmed);

    return absolute.TrimEnd(
        Path.DirectorySeparatorChar,
        Path.AltDirectorySeparatorChar);
}

If IsPathRooted returns false (which it will for any Windows-style path on Linux), skip GetFullPath entirely and use the trimmed value as-is. The path will still be wrong in the sense that D:\... is not a valid Linux path, but at least you have not silently corrupted it further. You can then validate it properly and return a clear error to the user.

The Deeper Problem: Host Paths vs Container Paths

Even with the fix above, there is a second issue worth understanding. When you run Docker on Windows, the paths inside the container are Linux paths, not Windows paths.

If your docker-compose.yml mounts a host directory like this:

volumes:
  - D:\Users\Downloads\my-project:/repos/my-project

Inside the container, that directory is available at /repos/my-project. The Windows path D:\Users\Downloads\my-project does not exist from the container's perspective at all.

So the correct path for a user to enter in your app's form is /repos/my-project, not the Windows path they see in File Explorer.

This is worth making explicit in your UI. In DevMetrics I added a hint directly on the Add Repository form:

In Docker, use the container path (e.g. /repos/my-project).

A one-line hint that prevents a lot of confusion.

The rule is simple: IsPathRooted is OS-aware. A Windows drive-letter path is not considered rooted on Linux, and GetFullPath will silently corrupt it as a result.

推荐订阅源