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

1 answer

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