Recreate a deleted temp directory instead of failing all later buffered requests

[VAllens]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When ASP.NET Core spills a large multipart request or a large buffered response to disk, it writes ASPNETCORE_*.tmp under ASPNETCORE_TEMP or Path.GetTempPath().

AspNetCoreTempDirectory caches that path for the process lifetime. If the directory is later missing (disk cleanup, an operator deleting the folder, Windows removing Temp\{sessionId}), the framework throws DirectoryNotFoundException instead of creating the directory it already resolved. Later requests that exceed the memory threshold keep failing until something outside the process recreates the folder.

For IFormFile binding this happens in FormFeature before user endpoint code runs, so the app cannot recover inside the action. Setting ASPNETCORE_TEMP to a “stable” folder does not help if that folder is deleted while the process is still running.

Related but not a duplicate of #42647 (locked). That issue was answered as: %TEMP% does not update after process start, so point ASPNETCORE_TEMP at a directory that already exists. This report is the other failure mode: the path is already known, but the directory was deleted.

Expected Behavior

Before creating ASPNETCORE_*.tmp, call Directory.CreateDirectory on the already resolved path (no-op if it exists). If create or the subsequent open fails (permissions, read-only volume), throw as today.

Do not change how the path is chosen (ASPNETCORE_TEMP then Path.GetTempPath()). Do not try to refresh %TEMP% or allocate a new Windows session-id folder.

Steps To Reproduce

1. Host an API that accepts IFormFile (multipart upload larger than FormOptions.MemoryBufferThreshold / the rewind threshold).
2. Optionally set ASPNETCORE_TEMP to a dedicated folder (the workaround from aspnetcore Abnormal prompt during operation  #42647), or use the default Path.GetTempPath().
3. Ensure the folder exists, start the app, and confirm the upload succeeds.
4. Delete that folder. Do not restart the process.
5. Repeat the same upload.

Exceptions (if any)

2026-08-18 17:26:12.676 [DBG] Reading the request body failed with an IOException. |7|System.IO.DirectoryNotFoundException: C:\Users\Administrator\AppData\Local\Temp\2\
   at Obfuscation.Web!<BaseAddress>+0x391f5
   at Obfuscation.Web!<BaseAddress>+0x1090d1
   at Obfuscation.Web!<BaseAddress>+0x10eeb0
--- End of stack trace from previous location ---
   at Obfuscation.Web!<BaseAddress>+0x3767b0
   at Obfuscation.Web!<BaseAddress>+0x378d07
   at Obfuscation.Web!<BaseAddress>+0x378c2b
   at Obfuscation.Web!<BaseAddress>+0x111b70
--- End of stack trace from previous location ---
   at Obfuscation.Web!<BaseAddress>+0x3767b0
   at Obfuscation.Web!<BaseAddress>+0x378d07
   at Obfuscation.Web!<BaseAddress>+0x378c2b
   at Obfuscation.Web!<BaseAddress>+0x4377e
--- End of stack trace from previous location ---
   at Obfuscation.Web!<BaseAddress>+0x3767b0
   at Obfuscation.Web!<BaseAddress>+0x378d07
   at Obfuscation.Web!<BaseAddress>+0x378c2b
   at Obfuscation.Web!<BaseAddress>+0x1d1e12

Often wrapped as:

Reading the request body failed with an IOException.

Typical stacks:

• Request: FormFeature.InnerReadFormAsync → FileBufferingReadStream.CreateTempFile → AspNetCoreTempDirectory.TempDirectory or new FileStream(...)
• Response: FileBufferingWriteStream.EnsureFileStream (same as aspnetcore Abnormal prompt during operation  #42647)

.NET Version

10.0.400

Anything else?

• ASP.NET Core version: current main (also observed on shipped versions that use AspNetCoreTempDirectory).
• OS: Windows (also applies anywhere the resolved temp directory can be deleted while the process is running).

Call path for IFormFile:

1. FormFeature.InnerReadFormAsync (src/Http/Http/src/Features/FormFeature.cs)
2. section.EnableRewind(...) → FileBufferingReadStream (src/Http/Http/src/Internal/BufferingHelper.cs)
3. Over threshold → FileBufferingReadStream.CreateTempFile() (src/Http/WebUtilities/src/FileBufferingReadStream.cs)
4. AspNetCoreTempDirectory currently throws if the directory is missing, and caches the path after the first successful lookup

I have a small patch ready (create the resolved directory in AspNetCoreTempDirectory and again immediately before creating the temp file in FileBufferingReadStream / FileBufferingWriteStream) and can open a PR against main if this approach is acceptable.

[github-actions]

Triage Summary

Area: area-networking (issue centers on AspNetCoreTempDirectory, FileBufferingReadStream, and FileBufferingWriteStream in src/Http/WebUtilities)
Type: Bug (reporter provides a concrete repro: deleting the resolved temp directory while the process is running causes DirectoryNotFoundException on subsequent buffered requests instead of recreating the directory)

Potential Duplicates

• None found

Notes

• Reporter states they have a patch ready (create the resolved directory in AspNetCoreTempDirectory, and again immediately before creating the temp file in FileBufferingReadStream/FileBufferingWriteStream) and offered to open a PR.

Generated by Issue Triage Agent for dotnet/aspnetcore for #68622 · auto · 30.6 AIC · ⌖ 3.13 AIC · ⊞ 27.4K · ◷

[MuhammadBilal64]

Thanks for the detailed report, @VAllens. I’d be interested in contributing a fix for this.
My plan would be to handle the missing resolved temp-directory case, add regression coverage for the directory being deleted while the process is running, and verify that the existing error behavior remains unchanged.
Since you mentioned you already have a patch ready, would you prefer to proceed with it, or would you be okay with me working on a PR as well?

[VAllens]

Thanks for the interest, @MuhammadBilal64
I just opened #69637​ with a fix for this.

One thing to flag: I haven't included tests in this initial push yet (the test checkbox is intentionally unchecked for now).
I wanted to get the core fix out first and iterate from there.
Since you mentioned wanting to add regression coverage for the mid-process deletion scenario, would you be open to collaborating on that?
Happy to pair on it or review your additions.

The fix itself calls Directory.CreateDirectory on every lookup and again before creating ASPNETCORE_*.tmp files, keeping path selection unchanged.

Would love your thoughts on the approach!

[MuhammadBilal64]

Thanks @VAllens, happy to collaborate on this. I'll write regression tests for a deleted temp directory, covering:

• FileBufferingReadStream (both the string and Func<string> overloads)
• FileBufferingWriteStream

How would you like me to deliver them? I can open a PR against your recreate-missing-temp-directory branch so the commits land in #69637 when you merge it, or I can paste the test file here for you to add.

One question on the approach: the PR removes the existing check that throws when the resolved directory doesn't exist on first lookup, so a mistyped ASPNETCORE_TEMP would now be silently created instead of failing fast. Was that intentional, or should the initial check stay and recreation only cover the directory disappearing later?

[VAllens]

Thanks @MuhammadBilal64. A PR against recreate-missing-temp-directory is the easiest way to land the tests in #69637.

I kept the first-lookup check. The first time the path is resolved, a missing directory still throws DirectoryNotFoundException, and the path stays uncached. That way a typo in ASPNETCORE_TEMP is not created, including any missing parents. Once the path is cached, Directory.CreateDirectory runs on every lookup and brings the directory back if cleanup or an operator deleted it. The call is a no-op when the directory is already there. Path selection is unchanged (ASPNETCORE_TEMP, then Path.GetTempPath()).

The CreateDirectory calls in FileBufferingReadStream and FileBufferingWriteStream stay. Callers can pass their own directory or accessor and never go through AspNetCoreTempDirectory. With TempDirectoryFactory, a missing directory still fails in the getter on first lookup, before those calls. A later deletion is recreated in both places.

For the tests, please pass a private directory into the stream, delete that directory, then read or write past the memory threshold. I would avoid deleting the process temp directory or depending on AspNetCoreTempDirectory's static cache. It is process-wide, and other tests may already have resolved it.

Coverage I have in mind:

• FileBufferingReadStream with a string directory
• FileBufferingReadStream with a Func<string> directory
• FileBufferingWriteStream

Please assert that the operation succeeds and the directory exists again.

[MuhammadBilal64]

Thanks @VAllens, I opened a PR against recreate-missing-temp-directory with the tests: VAllens#1

They follow your guidance. Each one passes a private directory into the stream, deletes it, and reads or writes past the memory threshold, then asserts it succeeds and the directory exists again. They cover the string and Func<string> read cases and the write case. They fail without your change and pass with it on Windows.