wslc build uses a stale build context after a Windows directory is deleted and recreated at the same path

[husseinkorly]

Windows Version

Microsoft Windows [Version 10.0.26200.8893]

WSL Version

2.9.4.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.35.2-1

Distro Version

No response

Other Software

• WSLC 2.9.4.0
• Docker Desktop, used only as a control to build the same recreated context successfully
• PowerShell on Windows

Repro Steps

1. In PowerShell, create a minimal build context:

   $context = Join-Path $env:TEMP "wslc-stale-context-repro"
   Remove-Item $context -Recurse -Force -ErrorAction SilentlyContinue
   New-Item -ItemType Directory -Path $context | Out-Null
   
   @'
   FROM busybox:latest
   COPY marker.txt /marker.txt
   RUN test -f /marker.txt
   '@ | Set-Content (Join-Path $context "Dockerfile") -Encoding ascii
   
   "first directory" | Set-Content (Join-Path $context "marker.txt") -Encoding ascii

2. Build the context:

   wslc build --no-cache --tag wslc-stale-context-repro $context

   The first build succeeds.

3. Delete the complete context directory and recreate it at the identical
   Windows path:

   Remove-Item $context -Recurse -Force
   New-Item -ItemType Directory -Path $context | Out-Null
   
   @'
   FROM busybox:latest
   COPY marker.txt /marker.txt
   RUN test -f /marker.txt
   '@ | Set-Content (Join-Path $context "Dockerfile") -Encoding ascii
   
   "recreated directory" | Set-Content (Join-Path $context "marker.txt") -Encoding ascii
   Get-ChildItem $context

   Get-ChildItem shows that Dockerfile and marker.txt exist.

4. Run the same WSLC build again:

   wslc build --no-cache --tag wslc-stale-context-repro $context

   WSLC reports that /marker.txt is not found.

5. Build the same recreated context with Docker Desktop:

   docker build --no-cache --tag docker-context-control $context

   Docker builds it successfully.

6. Copy the context to a new path and build it with WSLC:

   $newContext = "$context-new"
   Copy-Item $context $newContext -Recurse
   wslc build --no-cache --tag wslc-new-context-control $newContext

   WSLC builds successfully from the new path.

7. Terminate the WSLC session and retry the original path:

   wslc system session terminate
   wslc build --no-cache --tag wslc-stale-context-repro $context

   The original path works again.

Expected Behavior

Every wslc build invocation should read the current files from the build
context path supplied to that invocation.

After a Windows directory is deleted and recreated at the same path, WSLC
should detect that the underlying directory has changed and refresh or recreate
the context mount. COPY marker.txt /marker.txt should succeed because
marker.txt exists in the current context and is not excluded by
.dockerignore.

The result should not depend on whether the same path was used by an earlier
build in the current WSLC session. No session restart should be necessary.

Actual Behavior

The first WSLC build succeeds. After deleting the complete Windows context
directory and recreating it at the identical path, subsequent WSLC builds act as
if the recreated context does not contain marker.txt.

The failure includes:

failed to calculate checksum ... "/marker.txt": not found

Using --no-cache does not change the result.

The same recreated directory builds successfully with Docker Desktop. WSLC also
builds successfully when the files are copied to a different path. Running
wslc system session terminate makes the original path work again.

This suggests that WSLC retains a build-context mount associated with the
deleted directory object and reuses that stale mount when the same Windows path
is supplied again.

Diagnostic Logs

ERROR: failed to solve: failed to compute cache key: failed to calculate
checksum of ref a62b46cc-b843-4094-b82f-a20b93d48306:
"/marker.txt": not found

Error code: E_FAIL
Exit code: 1

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[husseinkorly]

added the error logs to the post under Diagnostic Logs

[ylwl1997]

This is a really clean repro — the control cases (Docker Desktop succeeds, new path succeeds, session terminate fixes it) isolate it well. The key clue is in that last one: the staleness is scoped to the WSLC session, not the path on disk.

That points to the build-context mount being cached per-session keyed by the Windows path string, without revalidating the underlying directory identity. When the directory is deleted and recreated at the same path, the mount still references the old directory object, so COPY marker.txt reads from the deleted directory's (now empty) view. --no-cache doesn't help because the staleness is in the mount, not the layer cache — which is consistent with checksum of ref ...: "/marker.txt": not found.

If the mount were keyed by directory identity (file ID / handle) rather than path string, the recreated directory would be seen as a new object and re-mounted. Worth checking whether the context mount is keyed by FILE_ID or by normalized path.

Practical impact for CI: this is the nasty one. Any pipeline that does rm -rf build && mkdir build between two wslc build steps (extremely common — checkout → clean → build) can silently build against stale content within the same session. The failure mode is also confusing because the first build succeeds and only subsequent ones break, so it's easy to misattribute to caching.

Workaround that doesn't need a session restart: if you can't change the directory path between builds, touch a path component (e.g. mkdir .wslc-ctx inside the context) so the supplied path string differs — though the cleaner fix is for the mount to revalidate on each build invocation.

I document wslc build behaviour (including context handling) in https://wslcontainers.com/commands/build/ and CI pitfalls at https://wslcontainers.com/guides/cicd/ — will add this stale-context gotcha to the CI guide.