Is there a zero-admin Windows alternative to FUSE for on-the-fly file reads? WebDAV fails on large files (0x800700DF)

I am building a portable encrypted vault application. On Linux, I use FUSE to create a virtual drive that intercepts OS file reads, allowing my app to stream decrypted 64 KB chunks into RAM strictly on-the-fly.

I want this FUSE-like behavior on Windows. The constraints are:

  1. Zero Administrator Rights: It must run entirely in user-space on locked-down host machines (e.g., lab PCs).

  2. Large File Support: Must support native Windows File Explorer transfers of large files.

  3. Zero Plaintext on Disk: Decrypted file chunks must stream into memory and never be written to the host computer’s SSD.

I haven’t verified whether the Windows WebClient service itself caches downloaded file data on disk, which would also break this constraint.

The Problem with Localhost WebDAV

Currently, I run a local Python WebDAV server mapped via net use Z: http://127.0.0.1:8080.

However, the built-in Windows WebClient refuses to read large files (Error 0x800700DF).

Minimal Reproduction (Windows 11 build 26200, WsgiDAV 4.3.5):

Terminal 1:

mkdir C:tempshare
fsutil file createnew C:tempsharebig.bin 60000000
fsutil file createnew C:tempsharesmall.bin 10000000
pip install wsgidav cheroot
wsgidav --host=127.0.0.1 --port=8080 --root=C:tempshare --auth=anonymous

Terminal 2:

net use Z: http://127.0.0.1:8080
copy Z:small.bin C:tempsmall_out.bin
copy Z:big.bin C:tempbig_out.bin

Output:

> net use Z: http://127.0.0.1:8080
The command completed successfully.

> copy Z:small.bin C:tempsmall_out.bin
> copy Z:big.bin C:tempbig_out.bin
copy : The file size exceeds the limit allowed and cannot be saved.
    + CategoryInfo          : NotSpecified: (:) [Copy-Item], IOException
    + FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Commands.CopyItemCommand

Oddly uploading large files works (I copied a 60 MB file into WsgiDAV and a 450 MB video into my own server). I haven’t worked out the exact size cutoff: the 10 MB file reads fine and the 60 MB file fails.

During the failed copy, the WsgiDAV log shows only PROPFIND requests for the large file and no GET, so the client seems to give up before requesting any data (I haven’t confirmed this).

On my machine, FileSizeLimitInBytes under HKLMSYSTEMCurrentControlSetServicesWebClientParameters is the default 0x2faf080 (50,000,000).

Approaches I’ve researched (that appear to be dead ends):

I haven’t built full implementations of the alternatives below. These conclusions come from reading documentation and from AI-assisted research, so some of them may be wrong. Everything above this section (the reproduction, the logs, the registry value, the upload tests) I ran myself. Please correct me where I’m mistaken.

  1. `subst` or symlinks: these look like plain path aliases, so I don’t see a way to intercept reads on demand without decrypting files to disk first.

  2. WebClient registry fix: the documented fix is raising `FileSizeLimitInBytes` under `HKLMSYSTEMCurrentControlSetServicesWebClientParameters`. It needs admin, and I haven’t tested it.

  3. WinFsp / ProjFS: WinFsp needs a kernel driver install, and ProjFS is an optional Windows feature that needs admin to enable.

  4. Cloud Filter API (`cldapi.dll`): it seems a standard user may be able to register a sync root, but it needs NTFS and hydrated files are written to disk. I’m not sure it works for a standard user from an unpackaged Python app.

  5. Local SMB server: Windows seems to connect to a non-445 port only from Windows 11 24H2 onwards (`net use Z: \127.0.0.1share /TCPPORT:10445`), and port 445 is already taken by the Windows Server service, so it won’t cover older machines.

The Question:

Is there any native Windows API, local protocol, or per-user workaround that allows a standard unprivileged user to expose a virtual drive or folder whose large-file reads are served by my own code?

  • Am I misunderstanding one of the APIs listed above?

  • Is there a way to trick WebClient into bypassing the 50 MB read limit without registry edits (e.g., chunked transfer encoding, spoofing PROPFIND sizes)?