Proper usage of FltReissueSynchronousIo

zigfrid

Hello folks!

Is it safe and legal to reissue opeartion that did not in fact failed? Documentation says "It typically calls FltReissueSynchronousIo from a postoperation callback routine to reissue a failed operation with different parameters" so I suppose it is not only about failed operations right?
Suppose I am at post create callback level and I see CreateFile operation that did not failed and I would like to reissue this operation with slightly changed parameters. Is that fine to call it (referring to non failed op)?

If so then is this API someone cancellng current IO or this is on me to cancel current IO once I reissued this operation? I am wondering how to say drivers below me (that already served post callback before) that this IO was not valid anymore.

Thank you for help

rod_widdowson

No you cannot.

You can do a FltCancelOpen, but that documentation states explicitly

Once the create operation has been canceled, it cannot be reissued. For more information, see FltReissueSynchronousIo.

In order to do what you want you need to look at shadow opens and that is a huge amount of work

zigfrid

Hi Rod,

Thank you for answer. Let me dig a bit:
1. I saw in doc section you quoted, but I was wondering about calling FltReissueSynchronousIo first and once it return to my code then call FtlCancelIo (everything from post create callback). Would it work?
2. Can you please emphasize your comment about "shadow opens"? I am not sure I follow your comment here.

Thank you again.

rod_widdowson

I saw in doc section you quoted, but I was wondering about calling FltReissueSynchronousIo first and once it return to my code then call FtlCancelIo (everything from post create callback). Would it work?

Nope. By the time you get to post call the files object is all set up so you cannot set it up again
 
As far as shadowing goes - think of it as not sending the create down in the pre-call, but rather sending your own create down (FltCreateFileEx). You then have a handle and you can do whatever you want with it. In full shadowing you then pretend to the filters above you that the the create they saw has been completed (and expect to aspend about 9-12 month elapsed to make this start to work. In your case you can just decide to mess around before you send down the create as before. But

• You need to worry about what you are going to do about relative opens
• You need to worry about constructive (FILE_CREATE) and destructive (FILE_OVERWRITE ...) creates
• You need to worry about defender getting in on the act
• You need to worry about strange ACLs on the directory (so a create might work once, but not twice)

It is a huge amount of effort. It is even more if you expect to make it work on the network.

zigfrid

Rod, again thank you for your valuable input.

Actually I wanted to avoid doing FltCreateFileEx at pre-callback for two main reasons:

• at pre create I dont know if process that is attempting to open file would ever succeed (due to ACLs for instance etc) and once I am at post I am sure OS allowed/failed this op. So it is kind of performance thing, because I would double opens that typically would fail and it was something I wanted to avoid and it was reason I was focusing on post callback.
• I have feeling making FileOpen on pre-create callback level (actually at post callback it looks same to me) will significantly increase chance of making sharing violations in the system won't it? This is becuase I will kind of double opens ;(. My goal is to make is as much transparent to the system as I can.

My original problem is one you mentioned: destructive create. In this case at post callback file is already destructed, meaning I cannot do anything with it's content (as it is wiped). I thought I could remove destructive flag in pre-callback, let it go (so it will succeed, but not wipe file) then at post reissue io with proper parameters, but from your previous comments it looks like it will not work.

Do you happen to have any other idea maybe?

Thank you once more.

rod_widdowson

I sort of mentioned it above, but you need to research IO_FORCE_ACCESS_CHECK (for your second point) and IO_IGNORE_SHARE_ACCESS_CHECK (for the first).

Local disk only but if you are doing this on the network you are doing this at the wrong place