1

Topic: File System Minifilter and a file at CLOSING

Specification of the previous subject. I save  to a file in everyone IRP_MJ_WRITE. With it all is excellent. I add it in the linked list, whether my function checks is not present there such at present, and writes to a broad gull, whether there was it (that is it is changed already existing) or the new is created. There all is more or less perfectly in order. However when I start in IRP_MJ_CLEANUP to search for it in this list coincidence and is not found out. With IRP_MJ_CLOSE - the same. Which  meant in the pre-previous paragraph? In the beginning was so: pFileObject = *Data-> Iopb-> TargetFileObject;... add_to_list (..., &pFileObject) As well as advised in the previous subject. (And as I understood it). But with it there was a problem, like as for the same open file at write them it turned out 2 (found out when made  through %d) - that one number another. And for simple FILE_OBJECT, pointerless - there is no operator ==. Therefore passed on fileObject. FsContext More this problem was not, however in IRP_MJ_CLOSE all the same quitted nothing, and, actually, in IRP_MJ_CLOSE this FsContext simply is always equal 0 as showed it . What it is possible to invent? To me it should be stored between write and close.

2

Re: File System Minifilter and a file at CLOSING

Hello, sergey77666, you wrote: S> In the beginning was so: S> S> pFileObject = *Data-> Iopb-> TargetFileObject; S>... S> add_to_list (..., &pFileObject) S> S> As well as advised in the previous subject. (And as I understood it). And what for you dereference TargetFileObject? It is an error. Here it is necessary to work not with structures FILE_OBJECT, and with pointers on them. And, for example, by search in the list to compare pointers, instead of structures. Then all will work. To everyone opened  (HANDLE) normally there corresponds one pointer on FILE_OBJECT. More shortly, in terminology of language of a C ++ it is correct so: std:: list <FILE_OBJECT *> myList; but not so: std:: list <FILE_OBJECT> myList; When to you comes IRP_MJ_WRITE - save the pointer (the pointer, instead of a structure copy!) on FILE_OBJECT, taken from Data-> Iopb-> TargetFileObject in the list. When comes IRP_MJ_CLEANUP - you search for this pointer in the list. Etc.

3

Re: File System Minifilter and a file at CLOSING

Hello, okman, you wrote: O> Hello, sergey77666, you wrote: S>> In the beginning was so: S>> S>> pFileObject = *Data-> Iopb-> TargetFileObject; S>>... S>> add_to_list (..., &pFileObject) S>> S>> As well as advised in the previous subject. (And as I understood it). O> And what for you dereference TargetFileObject? It is an error. And thought. But made differently. FsContext all the same comes in IRP_MJ_CLEANUP, here it and decided to use. Than badly?

4

Re: File System Minifilter and a file at CLOSING

Hello, sergey77666, you wrote: S> And thought. S> but made differently. FsContext all the same comes in IRP_MJ_CLEANUP, here it and decided to use. Than badly? In FsContext the file system stores the pointer on File Control Block / Stream Control Block (FCB/SCB), i.e. the data connected to a file or a flow. Two and more different FILE_OBJECT can have identical pointers FsContext (for example when two different  refer to the same file). If it does not confuse you - then all apprx. simple for minifilters to use FsContext it a little "not on feng shui", it is normally accepted or to use pointers on FILE_OBJECT, or contexts.

5

Re: File System Minifilter and a file at CLOSING

Hello, okman, you wrote: O> Hello, sergey77666, you wrote: S>> And thought. S>> but made differently. FsContext all the same comes in IRP_MJ_CLEANUP, here it and decided to use. Than badly? O> in FsContext the file system stores the pointer on File Control Block / Stream Control Block (FCB/SCB), O> i.e. the data connected to a file or a flow. Two and more different FILE_OBJECT can have identical O> pointers FsContext (for example when two different  refer to the same file). O> If it does not confuse you - then all apprx. simple for minifilters to use FsContext it O> a little "not on feng shui", it is normally accepted or to use pointers on FILE_OBJECT, or contexts. All the same on PFILE_OBJECT I will pass. And what for from a cyberforum left?

6

Re: File System Minifilter and a file at CLOSING

Hello, sergey77666, you wrote: S> And what for from a cyberforum left? Forums take away too much time. Sometimes dialogue at a forum is useful, there is an exchange of experience. Sometimes it turns in useless  time, not giving any . In my case the first smoothly flowed in the second.

7

Re: File System Minifilter and a file at CLOSING

Hello, okman, you wrote: O> Hello, sergey77666, you wrote: S>> And what for from a cyberforum left? O> forums take away too much time. O> sometimes dialogue at a forum is useful, there is an exchange of experience. Sometimes it turns in useless O>  time, not giving any . In my case the first smoothly flowed in the second. In general all is true. Only there still any odd fellow the day before wrote to you that from you any I pound and so forth. Here because of such how it, at a cyberforum is useless to sit (what their majority)?

8

Re: File System Minifilter and a file at CLOSING

Hello, sergey77666, you wrote: S> Only there still any odd fellow the day before wrote to you that from you any I pound and so forth. Coincidence)) is simple