Hi Gabriel:)
In this case,we don’t know when a stream file object would be created,how to let the filter recognize the FO is a stream file object or not? I find a doc in OSR,it mention a way to deal with the FO,the original text is :
"Managing File Objects
Few things continue to confound file system filter driver writers more than the issue of how to handle file objects within their filter driver. In Windows 2000, the introduction of a new function, IoCreateStreamFileObjectLite has made their task even more difficult than it was in the past.
Just to remind all of the file system filter driver writers: File Objects are not files. They are references to the actual file. Each time the file is opened, a new file object is created. Applications can open files. Filter drivers can open files. File Systems can open files. Many files are opened via IoCreateFile (this is the path that is used by applications and many kernel mode components). A few files are opened using IoCreateStreamFileObject and IoCreateStreamFileObject Lite.
Of course, a typical file system filter driver associates file objects together by using the FsContext field. While this works with all file systems, we note that in the case of network file systems the values of this field are often updated throughout the life of the file. This is because a network file system may not actually ?open? the file until an application begins to perform I/O against the file. We have even observed some redirectors that leave this field as NULL after the IRP_MJ_CREATE, only filling it in later, when they have the necessary information.
Probably the greatest difficulty facing file system filter driver writers are the file objects created by the file system itself. That is because normally the creation of a new file object is indicated to the filter driver via an IRP_MJ_CREATE but for file objects created by the file systems directly, there is no such indication.
In Windows NT 4.0, filter driver developers found that they did receive an IRP_MJ_CLEANUP for these file objects (created using IoCreateStreamFileObject) but in Windows 2000, the new call IoCreateStreamFileObjectLite eliminates even the IRP_MJ_CLEANUP call.
To work around this, we normally suggest that file system filter driver writers organize their data structures so that they maintain a per-file structure keyed on the FsContext value. Within each of the per-file structures, we then maintain a list of each file object associated with that file.
Then, during the processing of an IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_QUERY_INFORMATION, IRP_MJ_SET_INFORMATION, IRP_MJ_CREATE or IRP_MJ_CLEANUP operation we check to see if this file object is currently listed as one of the file objects associated with the given file. If it is not associated with the given file structure, we then associate it. This ensures that we will not discard the per-file structure prematurely.
Some of these files are internal control files for the FSD itself, and in that case your filter may not be tracking a per-file data structure for them at all. In most cases we ignore those files, but if they are important to your specific filter driver, this mechanism will allow you to detect and track them as well.
For network redirectors, we suggest monitoring the FsContext field before, and after, an I/O operation is processed by the underlying FSD; then, if the value of this field changes across the call, the filter can update its data structures accordingly."
Is it a best way to handle normal FO and stream FO?
