Supported pre-access block for OneDrive Cloud Files fetches in PowerShell 5.1?

Question

Supported pre-access block for OneDrive Cloud Files fetches in PowerShell 5.1?

CloudFilesPreflight 0

I need to run a read-only metadata preflight against an existing OneDrive-synced Windows folder using Windows PowerShell 5.1 x64 and possible helper processes. Before resolving or enumerating the first path in the sync root, I need a supported, verifiable, fail-closed safeguard against any fetch caused directly or indirectly by this preflight.

The safeguard must cover (1) remote file-data hydration, (2) on-demand directory population, including CF_CALLBACK_TYPE_FETCH_PLACEHOLDERS, and (3) restoration of file content from the provider's local cache. Reading metadata already present locally is acceptable. I cannot trigger an initial download just to activate Windows' reactive Block app feature. I have not tested against the source folder.

Is there a documented and supported mechanism for Microsoft's OneDrive sync client, rather than only for a custom Cloud Files provider, that can be enabled and checked without first accessing the sync root? Does it cover PowerShell 5.1, helper processes, ancestor path traversal, concurrent changes, and protection loss between the check and first access? Which Windows and OneDrive versions are supported? Do FILE_FLAG_OPEN_NO_RECALL or FILE_OPEN_NO_RECALL cover only an individual open, or can they protect enumeration and provider behavior too? Please link the specific documented guarantees for file data, directory data, and local-cache hydration, or state which parts are unsupported. We will test any proposed method on separate synthetic material before using real files.

0 comments

2 answers

Your answer

Answer 1

There is no documented, supported OneDrive control that can be enabled and verified before first access and that fail-closed blocks file hydration, directory population, and provider-cache restoration across PowerShell 5.1, helper processes, traversal, and concurrent activity.

For the stated requirement, do not run the preflight against the real sync root. Continue using separate synthetic material, and treat any direct path resolution, enumeration, attribute query, Shell operation, or helper invocation inside the real root as potentially provider-visible.

Coverage of the available mechanisms

Mechanism	What Microsoft documents	Meets the requirement?
Windows “Block app”	Available only after an automatic download starts: select Cancel download → Block app. The documentation describes blocking that app from downloading online-only files again. ^1^	No. It is reactive, so it cannot be armed without the initial download you ruled out. No documented guarantee covers helper processes, directory population, cache restoration, ancestor traversal, or a race-free check/use interval.
`FILE_FLAG_OPEN_NO_RECALL`	On `CreateFileW`, it says requested file data should remain in remote storage and not be transported locally; the flag is intended for remote-storage systems. ^2^	No. It is a flag on one open operation, not a sync-root policy. There is no documented OneDrive guarantee extending it to enumeration, other handles, child processes, or provider-initiated behavior.
`FILE_OPEN_NO_RECALL`	The native create option instructs offline-storage or virtualization filters not to recall file contents as a result of this open. ^3^	No. Its scope is the particular open. It does not establish a root-wide barrier or protect later operations and other processes.
`FILE_FLAG_OPEN_REPARSE_POINT`	Bypasses normal processing for the final reparse point and attempts to open the reparse point itself. ^2^	No. It is not documented as suppressing Cloud Files directory population, ancestor traversal, or unrelated provider activity.
Cloud Files hydration/population policies	These are policies selected by the sync provider when registering its sync root. Hydration policy is determined at file-open time, while population policy controls whether directory access causes namespace requests. ^4^	No for a OneDrive client application. They are provider contracts, not a consumer-side switch that PowerShell can impose on Microsoft OneDrive.
Placeholder-state queries	State can be derived from attributes and the reparse tag, but those values must first be obtained by listing the parent directory or querying the file. ^5^	No. This does not provide a pre-access barrier; obtaining the inputs already involves the namespace operations whose effects you need to avoid.

Why directory enumeration is not covered

Cloud Files explicitly defines separate provider callbacks:

CF_CALLBACK_TYPE_FETCH_DATA supplies file ranges needed for I/O or explicit hydration.
CF_CALLBACK_TYPE_FETCH_PLACEHOLDERS supplies directory contents in response to a directory query or an attempt to open a child beneath that directory. ^6^

Population policy determines the behavior:

ALWAYS_FULL: directory enumeration is never forwarded to the provider.
FULL: access to an incompletely populated directory requests all entries.
PARTIAL: it requests entries required by the application. ^4^

Those choices belong to the provider. No cited contract lets a PowerShell process override OneDrive’s registered population policy, and no no-recall open flag documents suppression of FETCH_PLACEHOLDERS.

Local-cache restoration is also not covered

Cloud Files distinguishes fetching absent content from validating content already present on disk. CF_CALLBACK_TYPE_VALIDATE_DATA permits a provider using VALIDATION_REQUIRED to validate previously transferred data before Windows completes user I/O. ^6^

The available documentation does not define a OneDrive consumer control that forbids restoration or reuse from OneDrive’s own local cache. OPEN_NO_RECALL only addresses transporting file data back from remote storage for the flagged open; it does not document cache-source restrictions.

Process and race guarantees

Nothing documented here provides:

inheritance from PowerShell to arbitrary helper processes;
protection for opens issued by antivirus, indexers, Shell extensions, or other concurrent processes;
coverage of ancestor-component resolution;
an atomic “verify protection, then access” transaction;
continued protection if OneDrive state changes between a check and the first access.

Cloud Files callbacks can occur concurrently on arbitrary provider threads, reinforcing that provider activity is asynchronous and not serialized around an application-side precheck. ^6^

Supported versions

The Cloud Files API and callback contracts start with Windows 10 version 1709 for desktop clients. ^6^ Files On-Demand is supported from Windows 10 Fall Creators Update and Windows Server 2019, but current OneDrive desktop support is Windows 10 22H2, Windows 11, or Windows Server 2022 and newer. ^7^ ^8^

These version floors indicate API and OneDrive availability; they do not add the requested safeguard. PowerShell 5.1 can call native APIs through compiled helpers or interop, but that does not broaden their documented scope.

References

Answer 2

Hello.

I can confirm you aren't going to find what you are looking for natively here. As you suspected with the reactive Block app feature, you would have to sacrifice a first fetch to actually trip the trigger, which defeats the purpose of your preflight zero trust constraint.

Regarding your specific question about FILE_FLAG_OPEN_NO_RECALL, the API scopes this behavior strictly to the handle tied to an individual file open event. Microsoft documentation notes this only tells the system not to restore a file's content from remote or offline storage on that specific open request. It does not put a blanket ban on the sync provider doing its job, nor does it configure sync root policies.

Standard path resolutions or ancestor traversals that naturally occur through commands like Get-ChildItem will fire Win32 FindFirstFile and file attribute calls that do not implement this flag globally. They can silently trip a placeholder fetch because there is no documented OneDrive guarantee extending the open no recall flag to enumeration calls, directory hydration, or helper processes. The older the PowerShell version, the worse this gets because version 5.1 natively lacks the built in bypasses to completely stop querying properties that trip provider responses under the hood.

Since any local operation executed against the physical sync path risks arbitrary hydration based on filesystem condition and client state, the approach of verifying exclusively locally pre access is unsupported if your margin for error is absolute zero. Your safest solution here for a pure metadata preflight without any fetch risks is ditching the Win32 local namespace traversals entirely. You will be better off moving your preflight query checks to the Microsoft Graph API, retrieving the folder state and metadata directly from the Microsoft cloud service before your PowerShell processes ever access the local filesystem tree.