create_file_direct_as_stream Method

Creates or opens a file by passing the request directly to the filesystem.

Syntax

def create_file_direct_as_stream(file_name: str, synchronize: bool, desired_access: int, creation_disposition: int, flags_and_attributes: int) -> CBFSFilterStream: ...

Remarks

This method should be used instead of the Windows API's CreateFile function to create or open a file when an application needs to access it without sending requests through the filesystem filter driver stack. If the file is created or opened successfully, this method returns a stream object that provides access to its data; otherwise, it returns None.

Since all requests against the file are routed directly to the filesystem (bypassing all filter drivers, including the class's), applications can use the returned stream within filesystem-related events without causing a system deadlock. (However, pay special attention to the Synchronize parameter's documentation, below.)

The FileName, DesiredAccess, CreationDisposition, and FlagsAndAttributes parameters correspond to the lpFileName, dwDesiredAccess, dwCreationDisposition, and dwFlagsAndAttributes parameters of the Windows API's CreateFile function (respectively). Please refer to Microsoft's documentation for more information on how to set these parameters appropriately.

The file is opened with a sharing mode that allows other processes open the file for any kind of operation.

The Synchronize parameter specifies whether this method and operations with the resulting handle should be synchronized with the thread that originated the underlying filesystem request associated with the current event (i.e., the event that this method was called from).

The parameter is applicable only when a caller uses it to open the file, for which the event was fired. Also, the parameter should not be set to true when this method is called from the on_after_close_file event - when the event is fired, there's no open file to synchronize operations with.

If Synchronize is True, this method and all operations with the resulting handle will be execute in the context of the external thread that originated the underlying filesystem request associated with the current event (which is important for on-the-fly file data modification like encryption, etc.), and the following restrictions will apply:

• The method may be called from any event handles with the exception of on_after_close_file and on_cleanup_context. Note: to be able to call the method from the on_before_create_file and on_before_open_file event handlers, set the AllowFileAccessInBeforeOpen configuration setting to True.
• The method should be called only for the file or directory that the event fired for.
• A file will be opened without buffering, which means that applications must comply with all restrictions imposed by the FILE_FLAG_NO_BUFFERING flag when reading and writing file data. Please refer to Microsoft's File Buffering article for more information.
• The DesiredAccess, CreationDisposition, and FlagsAndAttributes parameters are ignored.

If Synchronize is False, this method and operations with the resulting handle are executed in the context of the thread in hich the corresponding call is made, and the restrictions described above do not apply. This provides applications with greater flexibility since the returned file handle can be used in any event (so long as its handler complies with the general restrictions described by the Avoiding Deadlocks and Recursive Calls topics).

In both cases, the class must be active, i.e., it must be started using a call to the start_filter method.