Supported Windows mechanism for hard native-write and storage units

Branson Deeter 0 Reputation points
2026-09-22T22:22:03.2433333+00:00

We are assessing how to contain a native Windows workload, including Git subprocesses, before selecting an implementation.

We need a supported mechanism that prevents operations from exceeding predeclared limits on:

  • Allowed writable paths.
  • File and directory counts.
  • Individual file sizes.
  • Cumulative bytes written during an attempt, including repeated overwrites.
  • Total storage consumption.

Coverage must include the workload, a write-mediation component, a component maintaining authoritative lifecycle state, and attributable delegated writes such as logs and temporary files.

Our understanding is that NTFS space quotas do not account for repeated overwrites as cumulative writes, while Job Object I/O notification limits allow writing to continue after notification. Application-level reservations can enforce limits only where native effects cannot bypass them.

Which supported Windows interfaces can provide the missing enforcement, including memory-mapped writes, inherited or duplicated writable handles, and implicit service/database writes?

Please identify:

  1. Which limits the mechanism prevents before an overrun, versus detects afterward.
  2. Required Windows versions/editions, privileges, dependencies and provisioning.
  3. Coverage exclusions and whether an additional enforcement provider is necessary.
  4. Compatibility constraints for real Git subprocesses, redirected output handles and normal cleanup.

We treat the Windows kernel and the administrators controlling enforcement as trusted. We are not asking for protection against a malicious administrator or compromised kernel.

We request documentation and capability guidance only. We are not requesting deployment, configuration changes or paid work.

Windows development | Windows API - Win32
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Taki Ly (WICLOUD CORPORATION) 5,630 Reputation points Microsoft External Staff Moderator
    2026-09-23T02:05:59.7866667+00:00

    Hello @Branson Deeter ,

    I checked each of your points against the current documentation and ran a quick test on Windows 11 25H2, and your reading is right: there is no single built-in Windows mechanism that enforces all of those limits before the fact. Below is what I found for each one.

    For writable paths, NTFS ACLs with the workload running under its own SID, or an AppContainer, do prevent access at open time. The one thing to watch is inherited handles, because they keep the access they were opened with and the ACL is not checked again. I would restrict them at CreateProcess with PROC_THREAD_ATTRIBUTE_HANDLE_LIST rather than trying to police them afterwards.

    For total storage, an NTFS hard quota on that SID is genuinely preventive. In my test a 40 MB write failed with ERROR_DISK_FULL exactly at the 20 MB limit, and CreateFileMapping or extending a mapped file past the limit failed too, so mmap growth is covered. It does not count bytes written though: overwriting the same 1 MB region 100 times left quota usage at 1 MB. It also cannot be applied to Administrators, and files created by an elevated process or a service are owned by Administrators or SYSTEM, so quota simply does not bind to them. If you need a ceiling that applies to every writer regardless of token, the only built-in option I know of is a fixed-size VHDX used as the workspace volume.

    For cumulative bytes written, the Job Object JOB_OBJECT_LIMIT_JOB_WRITE_BYTES limit is detect-only, exactly as you suspected. The documentation says processes "continue to run and can continue to transmit read or write bytes beyond the specified limits". In my runs the notification arrived 2 to 8 seconds late, at 26 to 104 MB against a 10 MB limit, and memory-mapped writes were not counted at all. It can still be useful if a delayed TerminateJobObject is acceptable. I would not rely on SetIoRateControlInformationJobObject: it is a rate control rather than a cap, and its page states it is not supported on Windows 10 1607 and later.

    For per-file size and file or directory counts, I could not find any built-in mechanism, preventive or otherwise.

    On your numbered questions:

    1. Preventive: ACLs or AppContainer, NTFS hard quota, fixed VHDX. Detective: Job Object limits, IO_COUNTERS, the USN journal. Neither: file size and counts.
    2. NTFS quota needs an NTFS volume (not ReFS) and a non-admin SID; FSRM folder quotas exist but only on Windows Server. Job notification limits need Windows 8 or Server 2012 and later, and you should set neither breakaway flag so Git children stay in the job. AppContainer needs Windows 8 or later. Windows Sandbox needs Pro, Enterprise or Education. Attaching a VHDX needs admin.
    3. Yes, you need an additional provider for file size, counts and a hard cumulative cap, and the supported extension point for that is a file system minifilter. Windows even reserves a load-order group for it, "FSFilter Quota Management" at altitude 240000 to 249999, and a pre-operation callback can fail the operation before it reaches the file system. Memory-mapped writes do arrive at the filter as paging I/O, but the requesting process is often System, so I would attribute them through a file context captured at IRP_MJ_CREATE. The driver has to be signed through the Hardware Dev Center with an EV certificate, attestation signing for client and HLK for Server.
    4. Git runs fine inside a Job Object with breakaway disabled. Redirected stdio handles must be included in the handle list or the child will not get them. Quota and VHDX limits show up to Git as ERROR_DISK_FULL, which it treats as a normal write failure. TerminateJobObject leaves stale .lock files behind, and deleting the workspace clears them. I would avoid AppContainer for real Git because HOME, temp, config and credential helpers all need explicit grants.

    The pages I relied on:

    One note on scope: this forum does not have access to the Windows product source, internal design notes or the engineering teams, so I cannot issue an official support statement from here. The above is capability guidance from public documentation plus my own verification. If you need Microsoft to formally confirm the support boundaries, in particular for the minifilter route, a Windows developer support case is the right channel for that.

    Hope these information help! If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

    Thank you.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.