How to silently fail an I/O operation intercepted in minifilter driver

Question

We are attempting to intercept copy-paste events on our cloud drive mount, which is built using the Cloud Filter API (CfAPI) and a minifilter driver. Our objective is to intercept the I/O request, reject it at the driver level, and pass the source path to our CfAPI-based application. This would allow the application to initiate an in-place upload directly from the source, bypassing data duplication on the mount. Essentially, we are trying to mimic APFS-style cloning behavior on Windows for optimized disk utilization.

However, rejecting the I/O in the minifilter triggers a system-level popup, which results in a poor user experience. We require your expertise on the following:

Is there a mechanism to silently fail an I/O request from a minifilter driver without triggering a Shell/Explorer notification?

1. If a silent failure is not possible, is there an alternative way to programmatically convert a standard copy operation into a clone within the CfAPI framework?

We would appreciate your feedback on this at your earliest convenience.

Answer 1

Hi @Shakti Swarup Panda ,

Thanks for reaching out.

"Is there a mechanism to silently fail an I/O request from a minifilter driver without triggering a Shell/Explorer notification?"

You might want to consider returning a status code that Explorer interprets as "this file simply doesn't exist" rather than "access was blocked". Explorer just assumes the file isn't there and moves on quietly.

Per Microsoft's documentation on completing I/O operations in pre-operation callbacks, returning FLT_PREOP_COMPLETE tells the Filter Manager to stop passing the request down the stack - no lower minifilter or file system driver will see it. You set the final NTSTATUS in Data->IoStatus.Status, and that becomes the result the originating caller receives.

One thing I'd strongly emphasize here: make sure you're filtering strictly by Data->RequestorMode == UserMode before intercepting. Blocking kernel-mode requests unintentionally can destabilize the system. The Writing Pre-Operation Callback Routines documentation from Microsoft covers this filtering in detail and is worth reviewing closely.

"If a silent failure is not possible, is there an alternative way to programmatically convert a standard copy operation into a clone within the CfAPI framework?"

To be direct about it though: CfAPI does not expose a native "clone" or "server-side copy" primitive. The API is designed as a boundary layer between the OS and your sync engine, not as a data movement layer.

The approach I'd suggest is a two-part flow:

• Use the silent fail approach above to block the standard copy I/O from completing. At this point, use an IPC mechanism (an IOCTL from the minifilter to your user-mode service, or a named pipe/shared memory channel) to pass the source file path to your CfAPI sync engine application.
• Once your CfAPI app receives the source path, it can initiate an in-place upload directly from the source location to the cloud, and then use CfCreatePlaceholders to create a placeholder at the destination on the mount. From the user's perspective, the file "appears" at the destination without any actual local data duplication.

During the upload, you can use CfReportProviderProgress to surface transfer progress back through the sync engine, keeping the experience transparent to the user.

The full architecture for building a sync engine on top of CfAPI, including the placeholder and callback model, is documented in Microsoft's Build a Cloud Sync Engine guide - it's the most comprehensive reference for this kind of implementation and I'd recommend using it as your primary guide for the CfAPI side of things.

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

Answer 2

Silently failing an I/O operation in a minifilter driver without triggering a system-level notification is not straightforward. When a minifilter driver rejects an I/O request, it typically results in a notification to the user, which can degrade the user experience. Unfortunately, the Windows driver model does not provide a built-in mechanism to suppress these notifications directly when rejecting requests.

However, there are some strategies you might consider:

1. Vetoing with a specific reason: If you choose to veto the I/O operation, you can provide a reason that might not trigger a notification. This, however, may not guarantee a completely silent failure, as it depends on the specific context of the operation and how the system handles it.
2. Using the Cloud Filter API: Instead of rejecting the I/O operation outright, you could intercept the request and handle it in a way that leverages the Cloud Filter API (CfAPI) to perform the upload directly. This would involve modifying the behavior of the copy operation to initiate an upload rather than simply rejecting it.
3. Custom handling: Depending on your implementation, you might implement a custom mechanism within your application that listens for specific I/O requests and handles them accordingly, thus avoiding the need to reject them at the driver level.

If silent failure is not feasible, you may want to explore how to programmatically convert a standard copy operation into a clone within the CfAPI framework. This would likely involve utilizing the capabilities of the Cloud Filter API to manage the data transfer without traditional file system operations that trigger notifications.

---

References:

• BypassIO for filter drivers
• Supporting BypassIO operations