Catch creation of files and folders

NTFSD
1

Hello!

I have written a filter driver that catches a few file system events, like writing, reading…

What I need is to catch the creation of a file or a folder.

I have checked a few things using the FileSpy tool of OSR, and noticed that when I create

a file of a folder the IRP_MJ_CREATE is called, and that it has the information about what

was created. I know that I can get the name of the file/folder created by reading

IrpSp->FileObject->FileName. I also found in FileSpy that the tab of More Info has the

information if it is a file or a folder. My question is how can I get this information in my

driver. (I’m writing a legacy driver, not a minifilter). Also, how can I know if a file/folder

was created, and not something else invoked the Create IRP?

Thanks in advance!

1 Like
2

Are you looking for IrpSp->Parameters.Create.Options?
Check for FILE_DIRECTORY_FILE/FILE_NON_DIRECTORY_FILE

>Also, how can I know if a file/folder was created, and not something else invoked the Create IRP.

What do you really mean?

–
Sincerely
Maruf Maniruzzaman

3

Thank you for the help. But I still have a question.
What I do is getting the IrpSp and then print something everytime the statement
((IrpSp->Parameters.Create.Options)&FILE_DIRECTORY_FILE) is true.
Now I get many prints for every folder creation, and not only for folder creation. Even when I do a mouse right click my message is printed. This brings me to the question from the previous post.
I ask if I can know if it is a folder/file creation or it is something else, like file open…

Thanks!

4

you have to check for irp_mj_create’s flags if you want to check only a
file/folder creation (and not just read-only open)
See:
pIoStack->Parameters.Create.Options;
pIoStack->Parameters.Create.SecurityContext->DesiredAccess;

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, November 06, 2007 12:34 PM
Subject: RE:[ntfsd] Catch creation of files and folders

> Thank you for the help. But I still have a question.
> What I do is getting the IrpSp and then print something everytime the
> statement
> ((IrpSp->Parameters.Create.Options)&FILE_DIRECTORY_FILE) is true.
> Now I get many prints for every folder creation, and not only for folder
> creation. Even when I do a mouse right click my message is printed. This
> brings me to the question from the previous post.
> I ask if I can know if it is a folder/file creation or it is something
> else, like file open…
>
> Thanks!
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@asw.cz
> To unsubscribe send a blank email to xxxxx@lists.osr.com

5

What do you mean? What shoud I do with pIoStack->Parameters.Create.SecurityContext->DesiredAccess;?

I don’t want to change it, I just want to see when a file is created…

6

To recognize that file/directory was created you must check in your completion routine.

If ((Irp->IoStatus.Status == STATUS_SUCCESSS) &&
(Irp->IoStatus.Information == FILE_CREATED))
{
// file/directory created
}

Anyway the FILE_DIRECTORY_FILE/FILE_NON_DIRECTORY_FILE flags are not mandatory. One of them is set, if caller/API wants to ensure that open succeeds only if target is directory/file. For example when WIN32 API GetFileAttributes() is called it generates IRP_MJ_CREATE which doesn’t have any of these flags set. But in case the disposition requires creation it should be specified.

-bg

7

Alright, thank you very much! I will try it.

8

Hi Guys,

I used Parameters.Create.Options and FILE_DIRECTORY_FILE/FILE_NON_DIRECTORY_FILE to monitor files and directories open events under IRP_MJ_CREATE operation. They work fine for local file access. For remote file opening, however, it works the very first time after file created or updated, but not after. The Parameters.Create.Options was 0x01000140 at the first opening, and then it became 0x01000100 for later opening. I guess something blocked but don’t know how to release. Can you please help me to understand the problem?

Thanks,

Michael

9

Hello again,

If I create a completion routine, and catch the file / folder creation, will I be able to stop the operation, or I will see it only after the file / folder was created?
If I can’t, so can I catch the creation inside the Create IRP for me to prevent it’s completion?

Thanks!

10

Hello,

You can catch it in pre-create and fail the operation there. This is
ideally where you would want to do this, since the IRP has not
been received by the file system yet.

Instead of relying on the flags in pre-create, perhaps it would be
easier for you just to issue a FltCreateFile call with the FILE_OPEN
flag specified… If the call fails, the file does not exist and you can
then go from there…

If the create was issued with a FILE_OPEN_IF flag and you wait 'till
post create, you’re to late. The file will be created if it doesn’t exist
and problems can ensue from here on out.

Just my two cents. Good Luck

Matt

xxxxx@gmail.com wrote:

Hello again,

If I create a completion routine, and catch the file / folder creation, will I be able to stop the operation, or I will see it only after the file / folder was created?
If I can’t, so can I catch the creation inside the Create IRP for me to prevent it’s completion?

Thanks!

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

11

Hello,

I don’t understand what you mean when you say issue a FltCreateFile call with the FILE_OPEN flag, can you explain what you mean?
Also, why can’t get the name of the file created in the Create IRP itself? It seems like I have everything for it there…

12

zorbakov@.com wrote:

I don’t understand what you mean when you say issue a FltCreateFile call with the FILE_OPEN flag, can you explain what you mean?

I am assuming your working on a minifilter. My reference to
FltCreateFile was meant to be used as a way to probe if the file exist
already or not. If you specify
FILE_OPEN in the /CreateDisposition /parameter and the file does not
exist, the call to FltCreateFile will fail. If it fails with this flag
set during your pre-create,
that’s a very strong indication the file does not exist and the
IRP_CREATE is doing one of two things - attempting to open a file that
does not exist OR is attempting to create one.

Also, why can’t get the name of the file created in the Create IRP itself? It seems like I have everything for it there…

I never said you couldn’t get the name there… Technically, in
pre-create is the only valid place you can access the file name (except
with the minifilters helper
routines, which are beside the point).

All I’m saying is if you want to prevent files or folders from being
created, put your logic in pre-create and probe for them there… Flags
in the IRP heading down
the stack will not tell you what you need to know, you probably should
send your OWN create down and see if the file already exist or not
(block on the original Create and do this test).

I would recommend you look at FltCreateFile or ZwCreateFile’s
documentation and read up on those two flags (FILE_OPEN and
FILE_OPEN_IF) and base your logic on these calls return values (if you
get a handle or not).

Matt

13

Hello,
When FltCreateFile is issued with FILE_OPEN flag, the FSD tries JUST to OPEN the file and NOT CREATE it if it does not exist.

The logic here is, when you receive a Pre-Callback for IRP_MJ_CREATE, issue a FltCreateFile with FILE_OPEN flag. If the file exists, it will return STATUS_SUCCESS, else a failure status will be returned.

If you check this thing till completion routine (post-callback) and if the original call was made with a flag to open a file and create if it does not exist, the FSD will create the file and in completion routine, you can do nothing about it.

Of course, you can do the stuff in an ugly way in the completion routine. Check the IoStatus.Status. If it is FILE_CREATED, a new file has been created. Now issue a FltSetInformationFile with FileDispositionInformation set to delete the file.

Now you decide: Which is a better and a cleaner and an optimum way of checking if a file is being created and then stopping it.

Obviously, the one in completion routine is VERY BAD.

Regards,
Ayush Gupta

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, November 16, 2007 3:53 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Catch creation of files and folders

Hello,

I don’t understand what you mean when you say issue a FltCreateFile call with the FILE_OPEN flag, can you explain what you mean?
Also, why can’t get the name of the file created in the Create IRP itself? It seems like I have everything for it there…

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com

14

Ok, I will continue working on that. And I’m not writing a minifilter. I’m writing a legacy driver.

15

I have written a completion routine, but I never get any messages from it. It looks like this:

if((pIoStackIrp->Parameters.Create.Options)&FILE_DIRECTORY_FILE)
{
if(Irp->IoStatus.Information == FILE_CREATED)
{
DbgPrint(“A Folder Was Created.”);
}
}
else if((pIoStackIrp->Parameters.Create.Options)&FILE_NON_DIRECTORY_FILE)
{
if(Irp->IoStatus.Information == FILE_CREATED)
{
DbgPrint(“A File Was Created.”);
}
}

return STATUS_SUCCESS;

Why don’t I get anything?

16

Well thank you Sir,

Sometimes I need one of you guys that speaks English as a second
language to clarify what I trying to say…

This is sad, I need to go back to school and get an “edjumucation”! :slight_smile:

Matt

Ayush Gupta wrote:

Hello,
When FltCreateFile is issued with FILE_OPEN flag, the FSD tries JUST to OPEN the file and NOT CREATE it if it does not exist.

The logic here is, when you receive a Pre-Callback for IRP_MJ_CREATE, issue a FltCreateFile with FILE_OPEN flag. If the file exists, it will return STATUS_SUCCESS, else a failure status will be returned.

If you check this thing till completion routine (post-callback) and if the original call was made with a flag to open a file and create if it does not exist, the FSD will create the file and in completion routine, you can do nothing about it.

Of course, you can do the stuff in an ugly way in the completion routine. Check the IoStatus.Status. If it is FILE_CREATED, a new file has been created. Now issue a FltSetInformationFile with FileDispositionInformation set to delete the file.

Now you decide: Which is a better and a cleaner and an optimum way of checking if a file is being created and then stopping it.

Obviously, the one in completion routine is VERY BAD.

Regards,
Ayush Gupta

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, November 16, 2007 3:53 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Catch creation of files and folders

Hello,

I don’t understand what you mean when you say issue a FltCreateFile call with the FILE_OPEN flag, can you explain what you mean?
Also, why can’t get the name of the file created in the Create IRP itself? It seems like I have everything for it there…

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

17

zorbakov@.com wrote:

Ok, I will continue working on that. And I’m not writing a minifilter. I’m writing a legacy driver.

I hope you would take a look at the minifilter model, however, the same
logic will apply. Perhaps you should use IoSpecifyDeviceObjectHint.
Then again, from one posting on this forum, if I understood it
correctly, on systems that support Filter Manager calls to ZwCreateFile
will
not re-enter the top of the stack. Of all people, I believe Neal C. said
that, or perhaps I’m mistaken…

Matt

18

At a blind glance, it looks ok to me… What does your dispatch handler
look like, specifically your call to
IoSetCompletionRoutine?

In debugging do you even get to your completion routine or is it never
called?

Matt

xxxxx@gmail.com wrote:

I have written a completion routine, but I never get any messages from it. It looks like this:

if((pIoStackIrp->Parameters.Create.Options)&FILE_DIRECTORY_FILE)
{
if(Irp->IoStatus.Information == FILE_CREATED)
{
DbgPrint(“A Folder Was Created.”);
}
}
else if((pIoStackIrp->Parameters.Create.Options)&FILE_NON_DIRECTORY_FILE)
{
if(Irp->IoStatus.Information == FILE_CREATED)
{
DbgPrint(“A File Was Created.”);
}
}

return STATUS_SUCCESS;

Why don’t I get anything?

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

19

Hi MM,

Just a bit of confusion here.

I thought that Zwxxx (except ZwCreateFile) that use a handle returned by FltCreateFile do not go from top of the stack.

However, this handle should be closed only with FltClose.

And ZwCreateFile will come from top of the stack.

Please correct me if I am wrong.

From WDK documentation of FltCreateFile:



On versions of Windows earlier than Microsoft Windows Update Rollup for Windows 2000 SP4 and Microsoft Windows Server 2003 SP1, minifilter drivers should call FltCreateFile instead of IoCreateFile, IoCreateFileSpecifyDeviceObjectHint, or ZwCreateFile) to obtain a file handle for use with ZwXxx I/O routines such as ZwReadFile and ZwQueryInformationFile.



Regards,

Ayush Gupta

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Friday, November 16, 2007 4:55 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Catch creation of files and folders

zorbakov@.com wrote:

>Ok, I will continue working on that. And I’m not writing a minifilter. I’m writing a legacy driver.

>

>

I hope you would take a look at the minifilter model, however, the same

logic will apply. Perhaps you should use IoSpecifyDeviceObjectHint.

Then again, from one posting on this forum, if I understood it

correctly, on systems that support Filter Manager calls to ZwCreateFile

will

not re-enter the top of the stack. Of all people, I believe Neal C. said

that, or perhaps I’m mistaken…

Matt

—

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars

(including our new fs mini-filter seminar) visit:

http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in

To unsubscribe send a blank email to xxxxx@lists.osr.com

20

I think I *have* to be mistaken. I remember a thread where I interpreted
the statements to mean this and I remember
several other people questioned it… I believe this had to do with
re-entry…

I’m searching and can’t find any threads that remind me, or correct my
memory… I’m pretty sure I’ve confused things.

Matt

Ayush Gupta wrote:

Hi MM,

Just a bit of confusion here.

I thought that Zwxxx (except ZwCreateFile) that use a handle returned
by FltCreateFile do not go from top of the stack.

However, this handle should be closed only with FltClose.

And ZwCreateFile will come from top of the stack.

Please correct me if I am wrong.

From WDK documentation of FltCreateFile:


>
>
>
> On versions of Windows earlier than Microsoft Windows Update Rollup
> for Windows 2000 SP4 and Microsoft Windows Server 2003 SP1, minifilter
> drivers should call FltCreateFile instead of IoCreateFile,
> IoCreateFileSpecifyDeviceObjectHint, or ZwCreateFile) to obtain a file
> handle for use with ZwXxx I/O routines such as ZwReadFile and
> ZwQueryInformationFile.
>
>
>
>
>
>
>
>
>
> Regards,
>
> Ayush Gupta
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of MM
> Sent: Friday, November 16, 2007 4:55 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] Catch creation of files and folders
>
>
>
>
>
>
>
> zorbakov@.com wrote:
>
>
>
> >Ok, I will continue working on that. And I’m not writing a
> minifilter. I’m writing a legacy driver.
>
> >
>
> >
>
> I hope you would take a look at the minifilter model, however, the same
>
> logic will apply. Perhaps you should use IoSpecifyDeviceObjectHint.
>
> Then again, from one posting on this forum, if I understood it
>
> correctly, on systems that support Filter Manager calls to ZwCreateFile
>
> will
>
> not re-enter the top of the stack. Of all people, I believe Neal C. said
>
> that, or perhaps I’m mistaken…
>
>
>
> Matt
>
>
>
> —
>
> NTFSD is sponsored by OSR
>
>
>
> For our schedule debugging and file system seminars
>
> (including our new fs mini-filter seminar) visit:
>
> http://www.osr.com/seminars
>
>
>
> You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
>
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com