Bug in FltCancelFileOpen in Vista?

NTFSD
1

Hello

I try to cancel a creation of a file in PostCreat.

If I have a file named “image.jpeg” and try to copy the file it works and the name of the new file is “image – copy.jpeg” (my filter failed and it should cancel the creation of the file). If I then try to copy the first file “image.jpeg” again it does not work and no copy is made (my filter successfully cancel the creation of the file), but I can make a copy of the file “image – copy.jpeg” without problem (my filter failed again).

It seams that I can make a copy of a file if the name of the copy not exist. The default name of a file to be copied is “FileName – copy.jpeg and if that name exist I can not make a copy.

I use FltCancelFileOpen.

Is it a bug or is it me?
Or shall I use IRP to cancel the file open instead?

Regards
Mattias Bergkvist

2

You cannot rollback action which was taken in FSD based on “create disposition” in post-create. From FSD’s perspective the IRP is completed even if it is completing. Canceling generates IRP_MJ_CLEANUP & IRP_MJ_CLOSE for given FO which you will not see in your filter. You should probably consider modification of “create disposition” in pre-create.

-bg

3

xxxxx@netcleantech.com wrote:

Hello Mattias,

Perhaps you could supply a little more info about this operation. I’m a
little lost in your words here( :slight_smile: ).

If I’m understanding you correctly, and what your describing, sounds
kinda like a file_open/file_open_if type
logic error. I would suggest you have a second look at how your calling
FltCreateFile + flags, along with the operations
proceeding it. Sounds like your branched out in some sort of nested IF
statement where FltCreateFile could be called
differently in different branches of the “IF, ELSE, ELSEIF” statement…

Sorry, I can’t really express exactly what I’m thinking/too lazy to try.
If you could provide some debug info or code that
would really speed up the process. You have a logic problem in your code.

Hell, I’m just guessing for now, but on a Sunday morning - it’s the best
your going to get for now (without more info).

Good Luck and best wishes,

Matt

Hello

I try to cancel a creation of a file in PostCreat.

If I have a file named “image.jpeg” and try to copy the file it works and the name of the new file is “image – copy.jpeg” (my filter failed and it should cancel the creation of the file). If I then try to copy the first file “image.jpeg” again it does not work and no copy is made (my filter successfully cancel the creation of the file), but I can make a copy of the file “image – copy.jpeg” without problem (my filter failed again).

It seams that I can make a copy of a file if the name of the copy not exist. The default name of a file to be copied is “FileName – copy.jpeg and if that name exist I can not make a copy.

I use FltCancelFileOpen.

Is it a bug or is it me?
Or shall I use IRP to cancel the file open instead?

Regards
Mattias Bergkvist

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

4

xxxxx@netcleantech.com wrote:

It seams that I can make a copy of a file if the name of the copy not exist.
Just to clarify where I’m coming from, the above statement could
indicated wrong flags in a FltCreateFile
call, just latched onto this - I’m lost in the rest of what the OP is
trying to describe.

Matt

5

Hi Mattias,

This logic will fail whenever a new file is going to be created. This is because you are canceling the IRP in the Post routine.
If you remember, this was discussed in the very first posts that you had posted regarding minifilters long time back.
If you cancel/ fail the IRP in the Post routine of any IRP, you should “MANUALLY” rollback the changes that have been done.
If you look at it carefully, the problem is very straight forward: You allowed the IRP_MJ_CREATE to reach the FSD (since you passed it in the Pre callback); the FSD “Processed” the request (created the file in this case) and then a Post callback came. So, if you want to do things in the Post create callback, be prepared to undo the changes “yourself”… :slight_smile:

Regards,
Ayush Gupta

Meet people who discuss and share your passions. Join them now.

6

Ayush Gupta wrote:

Now I get what he was asking. This is absolutely correct in the sense
that the behavior he is seeing is
Mr. Explorer in action.

If he copies a file, then paste it into the same directory, then yes the
“FileName - COPY.ext” will show as the new
file. Do it a second time and he’ll see something like “FileName(2) -
COPY.ext”… I missed this the first time around.
Wasn’t thinking of the user/kernel linkage here… just driver behavior.

Mattias, Explorer.exe here is first probing for the file when a
copy/paste command is issued, then if a parent(duplicate) is
found, explorer issues a create with the FILE_OPEN_IF flag and just
creates a new file to copy the buffer too (with a
modified name).

As Ayush is telling you, in this scenario, the file is already created
before the post-opt is called. I think “Manually”
rolling back would be more trouble than probing for the file in pre-create.

I seem to of read over his statement that:
“I try to cancel a creation of a file in PostCreate.”

Matt

Hi Mattias,

This logic will fail whenever a new file is going to be created. This
is because you are canceling the IRP in the Post routine.
If you remember, this was discussed in the very first posts that you
had posted regarding minifilters long time back.
If you cancel/ fail the IRP in the Post routine of any IRP, you should
“MANUALLY” rollback the changes that have been done.
If you look at it carefully, the problem is very straight forward: You
allowed the IRP_MJ_CREATE to reach the FSD (since you passed it in the
Pre callback); the FSD “Processed” the request (created the file in
this case) and then a Post callback came. So, if you want to do things
in the Post create callback, be prepared to undo the changes
“yourself”… :slight_smile:

Regards,
Ayush Gupta

Meet people who discuss and share your passions. Join them now.
http:
> — 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</http:>

7

Hi Mattias,

This logic will fail whenever a new file is going to be created. This is because you are canceling the IRP in the Post routine.
If you remember, this was discussed in the very first posts that you had posted regarding minifilters long time back.
If you cancel/ fail the IRP in the Post routine of any IRP, you should “MANUALLY” rollback the changes that have been done.
If you look at it carefully, the problem is very straight forward: You allowed the IRP_MJ_CREATE to reach the FSD (since you passed it in the Pre callback); the FSD “Processed” the request (created the file in this case) and then a Post callback came. So, if you want to do things in the Post create callback, be prepared to undo the changes “yourself”… :slight_smile:

Regards,
Ayush Gupta

8

Thanks you all for the answers.

Ayush Gupta wrote:

So, if you want to do things in the Post create callback, be
prepared to undo the changes “yourself”… :slight_smile:

Yes and I do that, I undo the changes by my self.
I do this that I have taken from the scanner example in the winddk that also is don in post create.
FltCancelFileOpen( FltObjects->Instance, FltObjects->FileObject );
Data->IoStatus.Status = STATUS_ACCESS_DENIED;
Data->IoStatus.Information = 0;

All is don in PostCreat. The strange thing is that it all works in xp and server 2003 but not in Vista.

Matt wrote:

I think “Manually” rolling back would be more trouble than probing for the
file in pre-create.

Yes I have tried that too but when I call FltQueryInformationFile in Pre Create it is failed and I thing it is because the file is not open.

The comment for PostCreate method in the Scanner example says this:
We can’t scan the file until after the create has gone to the filesystem, since otherwise the filesystem wouldn’t be ready to read the file for us.

So therefore I think I most do everything in post create.

Are there anybody that know what is wrong here?

Regards
Mattias Bergkvist

9

>Yes and I do that, I undo the changes by my self.
Just warning. In case CreateDisposition is FILE_SUPERSEDE or FILE_OVERWRITE you cannot rool-back action which was taken by FSD. FSD deletes the file if it exists. So how would you roll-back this?

We can’t scan the file until after the create has gone to the filesystem, since
otherwise the filesystem wouldn’t be ready to read the file for us.

So therefore I think I most do everything in post create.

Are there anybody that know what is wrong here?
I guess it is not your case. You are not going to read from the file when you cancel its openning/creation.

-bg

10

Bronislav Gabrhelik wrote:

I guess it is not your case. You are not going to read from the file when you
cancel its openning/creation.

My algorithm is calculated on the hole file and therefore I most read the file with FltReadFile in PostCreate.

Regards
Mattias Bergkvist

11

>We can’t scan the file until after the create has gone to the

filesystem, since otherwise the filesystem wouldn’t be ready to read
the file for us.

So therefore I think I most do everything in post create.

Are there anybody that know what is wrong here?

I’m still a little fuzzy on what you’re trying to do here, but if you
need to scan the file to determine what action to take, why not try
opening it yourself with a non-destructive disposition? FILE_OPEN would
be a good choice, and you have all of the other information you need (in
the callback_data) to issue an FltCreateFile.

~Eric