1

Topic: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Here such code. Creation of files in the usual sense should "fly to a broad gull" only. Not folders. And not discovery, namely creation. But this all flies. Clearly that it is necessary to check something still. Who can prompts? It is desirable in Pre - though in this case would approach and Post-. I think so: - before creation to check, what the file is not present, and on parameters to check, what in dataful parameters it should be created (but how to check, what it is not present, without opening it? And it not the best variant - and suddenly something prevents creation? It is better to have BOTH is and before, and upon) - and on folders I do not know where in parameters. With  SSDT worked, there was this problem. All right, passed to filters - and again it. Really it was impossible though one normal API to make, hosspidja-you-bozezmoj... FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback (__ inout PFLT_CALLBACK_DATA Data, __ in PCFLT_RELATED_OBJECTS FltObjects, __ deref_out_opt PVOID *CompletionContext) {PFILE_OBJECT FileObject; if (FLT_IS_FS_FILTER_OPERATION (Data)) {return FLT_PREOP_SUCCESS_NO_CALLBACK;} if (FltObjects-> FileObject! = NULL && Data! = NULL) {FileObject = Data-> Iopb-> TargetFileObject; if (FileObject! = NULL && Data-> Iopb-> MajorFunction == IRP_MJ_CREATE) {//here still check FltObjects-> FileObject-> FileName on NULL and it }} return FLT_PREOP_SUCCESS_NO_CALLBACK;}

2

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Hello, sergey77666, you wrote: S> only creation of files in the usual sense. Not folders. There will be all. S> and not discovery, namely creation. This, by itself, is impossible before file stock-taking. Check Disposition in Parameters in certain cases can help. Create. Options. S> it is better to have BOTH is and before, and upon). S> Really it was impossible though one normal API to make, hosspidja-you-bozezmoj... "Normal" is such in which faster and is most easier your task dares?

3

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Hello, sergey77666, you wrote: S> Here such code. Creation of files in the usual sense should "fly to a broad gull" only. S> not folders. S> and not discovery, namely creation. S> but this all flies. S> it is clear that it is necessary to check something still. Who can prompts? It is desirable in Pre - though in this case would approach and Post-. The field Data-> Iopb-> Parameters See. Create. Options: FLT_PARAMETERS for IRP_MJ_CREATE union https://msdn.microsoft.com/en-us/librar … 2147217396 Options Bitmask of flags that specify the options to be applied when creating or opening the file, as well as the action to be taken if the file already exists. The low 24 bits of this member correspond to the CreateOptions parameter to FltCreateFile. The high 8 bits correspond to the CreateDisposition parameter to FltCreateFile. Well i.e. in seniors 8 bits there will be one of flags FILE_CREATE, FILE_OPEN_IF etc. On which it is possible to distinguish modes of creation/opening of a file from each other, it is detailed they are described in docks to ZwCreateFile/FltCreateFile. To distinguish a file from a folder it is possible, for example, by means of FltIsDirectory, only to call her it is necessary from Post-kalbeka. Still, probably, it is necessary to filter discovery of volumes (DASD open), in samples from WDK it do so: BOOLEAN IsVolumeOpen (_In_ PFLT_CALLBACK_DATA Cbd) / * ++ Routine Description: This routine returns if the target object in this callback datastructure is a volume. If the file object is NULL then assume this is NOT a volume file object Arguments: Cbd - Supplies a pointer to the callbackData which declares the requested operation. Return Value: TRUE - target is a volume FALSE - target is not a volume - */{PAGED_CODE (); if ((Cbd-> Iopb-> TargetFileObject! = NULL) && FlagOn (Cbd-> Iopb-> TargetFileObject-> Flags, FO_VOLUME_OPEN)) {return TRUE;} else {return FALSE;}}

4

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Hello, sergey77666, you wrote: S> Here such code. Creation of files in the usual sense should "fly to a broad gull" only. S> not folders. S> and not discovery, namely creation. S> but this all flies. Well, after all even normal CreateFile from Winapi also creates and opens. (Because should be such  which creates and opens, differently there will be a race at file copying) And it works both with files and with folders (with , with , with mount points, with volumes). In FLT_PARAMETERS for IRP_MJ_CREATE union in the field Options there is a such: * Disposition bits (to create or open) * CreateOptions bits (among them FILE_DIRECTORY_FILE and FILE_NON_DIRECTORY_FILE) But there is a pair of nuances: * Disposition can resolve both creation and discovery (a variant " and if is not present - to create", or another "to create and if is - to clear and open") * Can be not set neither FILE_DIRECTORY_FILE, nor FILE_NON_DIRECTORY_FILE to Struggle with ambiguous Disposition it is possible,  applying post-processing, IO_STATUS_BLOCK will contain in the field Information values FILE_CREATED, FILE_OPENED, FILE_OVERWRITTEN...

5

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Hello, okman, you wrote: O> Well i.e. in seniors 8 bits there will be one of flags FILE_CREATE, FILE_OPEN_IF etc. on which it is possible to distinguish O> modes of creation/opening of a file from each other, is detailed they are described in docks to ZwCreateFile/FltCreateFile. Yes about IoStatus I know, but only FILE_OPEN_IF etc. can cause already at an existing file! Not for all cases such operating time approach. For example, in a case with  which somewhere creates the file of a plug-in to any software (that is forbidden without involvement of the user) to virus protection creation (immediately through CreateFile or through CopyFile will be interesting to trace), instead of opening of already created file, let us assume, on 10 times for a day on purpose something to change. Or, anyway, differentiation of the first from the second is necessary. O> to distinguish a file from a folder it is possible, for example, by means of FltIsDirectory, only to call her it is necessary from Post-kalbeka. Not so a buzzing. If it is impossible to define on any input parameters NtCreateFile, the file it forms or a folder as the kernel defines, what to it to create? O> still, probably, it is necessary to filter discovery of volumes (DASD open), in samples from WDK it do so: Except folders and files there still is ? APPRX.

6

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Hello, Alexander G, you wrote: AG> * Can be not set neither FILE_DIRECTORY_FILE, nor FILE_NON_DIRECTORY_FILE That then the system makes? AG> to Struggle with ambiguous Disposition it is possible,  applying post-processing Simply to define in Pre-kallbeke, whether there is such file (to a call) or not - in any way? All right.

7

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Hello, Evgenie Muzychenko, you wrote: I eat> "Normal" is such in which faster and is most easier your task dares? The task at all only mine. Dispute will not be. To be able to distinguish convenient from inconvenient is it is necessary to be born. And to live not too well. And to understand that the Microsoft of anything would not need to be made 10 different API - especially.

8

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Hello, sergey77666, you wrote: AG>> * Can be not set neither FILE_DIRECTORY_FILE, nor FILE_NON_DIRECTORY_FILE S> That then the system makes? If was nothing, and Disposition allows to create - creates a file. If something was, and Disposition allows to open - opens both a file, and a folder. (Generally about such questions - it is possible to try to cause NtCreateFile from ntdll.dll in usermode application and to look that will be)

9

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

S> Here such code. Creation of files in the usual sense should "fly to a broad gull" only. S> not folders. S> and not discovery, namely creation. S> PreFileOperationCallback (at once - an error in design. Before operation execution in any way it will be impossible to know a file it is created or opened existing since such operations 100500 pieces can arrive simultaneously and which of them as a result the file creates and what appear  - will be clear only a post factum after requests fly by through . So search for the answer in Post FileOperationCallback

10

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

Hello, ononim, you wrote: S>> Here such code. Creation of files in the usual sense should "fly to a broad gull" only. S>> not folders. S>> and not discovery, namely creation. S>> PreFileOperationCallback (O> at once - an error in design. Before operation execution in any way it will be impossible to know a file it is created or opened existing since such operations 100500 pieces can arrive simultaneously and which of them as a result the file creates and what appear  - will be clear only a post factum after requests fly by through . O> So search for the answer in Post FileOperationCallback It agree, an error in design of it API. And not that the error, and simply is not present any design, simply nobody took care, that it was not such what it and is (what it easier to make), and it was really convenient to use it. If monitoring, how many possibility to forbid file creation it is deep  is necessary not so much even, how many there operations arrives to this file. All the same either to forbid everything, or to resolve all. And also it is deep, whether it there it will be really created or prevents we tell shortage of a place on a disk - attempt it to create is important. And attempt to create can be defined on presence of one of the flags, capable to create a file, PLUS on absence of a file to a call. But here is how normally to check up last, and not to cause it a recursion (Create) - I yet I do not know. In the given driver I will apply Post. This driver - only . What for it generally is necessary, I do not know. The customer very reserved type. But, say, if it is such  for   a software, like obvious that it would be not necessary to pass attempts to create unlawful (and by that to leave  without attention!) only that they for any reason failed... So, Pre it is better...

11

Re: IRP_MJ_CREATE, the minifilter. How to distinguish CREATION a file

S>>> PreFileOperationCallback (O>> At once - an error in design. Before operation execution in any way it will be impossible to know a file it is created or opened existing since such operations 100500 pieces can arrive simultaneously and which of them as a result the file creates and what appear  - will be clear only a post factum after requests fly by through . O>> So search for the answer in Post FileOperationCallback S> It agree, an error in design of it API. You work not in MSDOS, and in multitasking operating system. Implementations of yours  means global  over all operations with file system that at once sweeps aside possibility of a heap different  at level of a sheaf of drivers FS and the block device under it, without speaking about network file systems. But if it is direct it is necessary - such  you can create that, truth it does not help with network  - on a remote server the file can be created far off with perfect other computer where there is no your driver generally. S> And not that the error, and simply is not present any design simply nobody took care, that it was not such what it and is (what it easier to make), and it was really convenient to use it. The operating system is created optimally to work with the equipment. Everyones  for developers of an unnecessary software of everyones  - the optional bonus, which functional is restricted by primary requirements.