I wonder why CbFsHandleInfo* is not passed to OnReadFile and OnWriteFile callbacks. A context with which the file was open may be necessery there. For example, my remote file system in read/write handlers expects file descriptor which was returned on open call and all open calls have to be distinguishable for some reasons.
Is it possible to do this some way?

In Windows the read and write requests in several cases don't have association with the file opening (file handle). For example:
1. A process opens a file (and CBFS calls the OnOpen callback then).
2. By the use of the obtained file handle the process creates a memory mapped section, for example by means of CreateFileMapping + MapViewOfFile API. CBFS doesn't know about these operations and no one callback is being called at this time.
3. The process closes the handle to the file (and CBFS calls the OnCleanup callback).
4. In the case the memory mapped section has a name, another process can also open this memory mapped section. CBFS again doesn't know about it and therefore doesn't call any callback.
5. The processes start to "copy to" and "copy from" their memory mapped sections. It causes the system memory manager to ask the file system to write/read data to/from the file. CBFS in this case calls the OnRead and OnWrite callbacks, but it doesn't know what a process is the real originator of these requests. Moreover the system memory manager can delay flushing (writing) to the file. I.e. several writings to the memory mapped sections can
occur and these writings can overwrite each other and only then only one write request can come to the file system (i.e. only one the OnWrite callback will be called).
6. After all of the memory mapped sections are closed CBFS calls the OnClose callback.

As a variant you can prevent a file from opening (based either on the requested access rights, or on the name of the process, or the process token) by returning the "access denied" error and it causes the originator process not to obtain a handle to the file and therefore won't be able to perform any operations with the file.

Sorry to dig up an old thread, but I'm trying to fix issues related to handle and read/write operations.
We switched to using SetCallAllOpenCloseCallbacks(TRUE)
I understand HandleInfo is not a parameter to ReadFile/WriteFile callbacks.

Operation system handles these cases itself. It is done in such a way - with each handle the list of access rights is associated and when the process 1 tries to write to the file by the use of h1 the operation system checks whether the handle has access right FILE_DATA_WRITE (it's part of GENERIC_WRITE) and if it isn't present then immediately returns ERROR_ACCESS_DENIED. The file system driver even doesn't receive any request in this case.
But, some kernel mode code (e.g. some antivirus driver) can open a file even with zero access rights and then manually generate "write" request and send it to the file system driver. So in the case of CBFS you still get the OnWrite callback even with the zero access rights handle.
The common practice for file systems is to check access rights during file creation/opening and if the access is denied then return the "access denied" error.

In my backend, each open file ("handle") is associated with a file descriptor, which are "persisted" in the handleInfo->UserContext
So, I guess I also have to maintain a list of these descriptors in the FileInfo->UserContext, and pick the right one to perform the read/write operation with the correct descriptor.

The read and write operations don't have HandleInfo parameter because often it doesn't exists for them. For example a file is opened as a memory mapped section. I.e. a program can open a file (get a handle to it), create a memory mapped section (MapViewOfFile, etc), close the handle (the OnCleanup callback is called at that time), and only then perform read/write by the use of memory mapped section. The read and write requests for this case are not associated with any file handle. Moreover several programs can do the same at the same time and then read/write to the file memory section concurrently. And on the file system level it isn't possible to get information what a program really performed operations.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.