OpenFile Event

Fires when the OS wants to open a file or directory.

Syntax

virtual int FireOpenFile(CBFSOpenFileEventParams *e);
typedef struct {
const char *FileName;
int DesiredAccess;
int Attributes;
int ShareMode;
int NTCreateDisposition;
int NTDesiredAccess;
int64 FileInfo;
int64 HandleInfo;
void *FileContext;
void *HandleContext;
int ResultCode; int reserved; } CBFSOpenFileEventParams;
virtual INT FireOpenFile(CBFSOpenFileEventParams *e);
typedef struct {
LPCWSTR FileName;
INT DesiredAccess;
INT Attributes;
INT ShareMode;
INT NTCreateDisposition;
INT NTDesiredAccess;
LONG64 FileInfo;
LONG64 HandleInfo;
LPVOID FileContext;
LPVOID HandleContext;
INT ResultCode; INT reserved; } CBFSOpenFileEventParams;

Remarks

This event fires when the OS wants to open the existing file or directory specified by FileName using the open options reflected in Attributes. If the FireAllOpenCloseEvents property is disabled, this event will only fire when the first handle to the specified file or directory is opened. To determine whether the request is for a file or a directory, compare Attributes against the Windows API's FILE_ATTRIBUTE_DIRECTORY (16, 0x10) constant, like so:

// Check whether the request is for a file or a directory.
bool isDirectory = Attributes & FILE_ATTRIBUTE_DIRECTORY == FILE_ATTRIBUTE_DIRECTORY;

If the UseAlternateDataStreams property is enabled, this event also fires anytime the OS wants to open a named data stream in a file. Such requests are distinguished by the presence of a colon (:) in the FileName value; the text before the colon is the name of the file itself, and the text after the colon is the name of the stream to open.

To handle this event properly, applications should perform any actions needed to open the requested file, directory, or named stream in their backend storage. Applications are also responsible for validating the access rights of the process that initiated the request before performing the requested operation; please refer to the Security Checks topic for more information.

If there's an existing local file that corresponds to the virtual one specified by FileName, the application may call RouteToFile to have the class route future requests directly to that file. This event's FileInfo value must be passed to RouteToFile for request routing to be configured successfully.

In certain cases, this event may fire for a file or directory that no longer exists. Normally this won't happen, as the OS already knows which files exist (based on information obtained via GetFileInfo/EnumerateDirectory) before it sends the open request. However, if a file or directory is deleted externally, a race condition may occur where said deletion isn't detected by the OS or virtual filesystem before the open request arrives. In such cases, applications must return the ERROR_FILE_NOT_FOUND error code via ResultCode.

The DesiredAccess parameter specifies the access mode desired by the process that initiated the request. This value may differ from the one originally passed to the OS; the class alters it in the following cases:

  • The DELETE flag is added if the requested CreateDisposition is FILE_SUPERSEDE.
  • The FILE_WRITE_DATA, FILE_WRITE_EA, and FILE_WRITE_ATTRIBUTES flags are added if the requested CreateDisposition is FILE_OVERWRITE or FILE_OVERWRITE_IF.
The original CreateDisposition and DesiredAccess values are exposed via the NTCreateDisposition and NTDesiredAccess parameters. (Note that these values are in NT format; i.e., as expected by the Windows API's ZwCreateFile function.)

The Attributes parameter specifies both the attributes and create/open options for the new file. Some options, such as FILE_FLAG_SEQUENTIAL_SCAN, FILE_FLAG_WRITE_THROUGH, FILE_FLAG_RANDOM_ACCESS, etc.; may be useful for applications that wish to fine-tune their performance. For example, such information could be used to decide whether it's necessary to locally cache some amount of data that is stored remotely.

The ShareMode parameter specifies the access sharing mode desired by the process that initiated the request.

Please refer to the Windows API's ZwCreateFile function for more information about possible values for the DesiredAccess, Attributes, ShareMode, NTCreateDisposition, and NTDesiredAccess parameters.

The FileInfo parameter carries a handle to an object with information about the file. As mentioned above, this value should be used if the application chooses to call the RouteToFile method.

The HandleInfo parameter carries a handle to an object with information about the file handle. While within the event handler, it can be used to call any of the following methods: GetHandleCreatorProcessId, GetHandleCreatorProcessName, GetHandleCreatorThreadId, or GetHandleCreatorToken.

The FileContext and HandleContext parameters are placeholders for application-defined data associated with the file and specific handle, respectively. Please refer to the Contexts topic for more information.

The ResultCode parameter will always be 0 when the event is fired. If the event cannot be handled in a "successful" manner for some reason (e.g., a resource isn't available, security checks failed, etc.), set it to a non-zero value to report an appropriate error. Please refer to the Error Reporting and Handling topic for more information.

 
 
Copyright (c) 2020 Callback Technologies, Inc. - All rights reserved.
CBFS Connect 2020 C++ Edition - Version 20.0 [Build 7545]