Reparse from post-create, limitations?

NTFSD
1

List,

I intend to reparse create requests from post-create and am now facing a couple of problems. I want to handle requests that are failing with STATUS_OBJECT_PATH_NOT_FOUND or STATUS_OBJECT_NAME_NOT_FOUND. I want to sometimes reparse these requests and sometimes pass them on unmodified.

Problems:

1-- I am unable to successfully use FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_OPENED… if the create request is failing. The function will then fail with STATUS_FLT_INVALID_NAME_REQUEST. Has anyone else seen this? Is it by design? As a test I tried to not release the file name information in pre-create. It had no apparent effect.

I would prefer to not allocate a buffer and copy the file name for every create request.

2-- There is no corresponding FLT_PREOP_DISALLOW_FASTIO for the post-create path. I believe, being in the post-create path already, this is just a flag that needs to be communicated to the I/O manager. Perhaps there is some way to solve this?

Many thanks in advance,
Otto

2

Hi Otto,

First, the STATUS_FLT_INVALID_NAME_REQUEST status from
FltGetFileNameInformation is by design. You will probably need to query the
name in preCreate and pass a pointer to the name structure to the postCreate
routine through the Context parameter and then call
FltReleaseFileNameInformation from the postCreate once you’re done using it
(that’s how I’d do it at least). This way you can tell what the user tried
to open originally. You should probably try the opened name since it has
lower impact on system resources.

I’m not sure what you’re trying to achieve for your second problem. When and
why would you call FLT_PREOP_DISALLOW_FASTIO if it were available ?

Thanks,
Alex.

3

Hi Alex,

Thank you for the tip regarding #1. I had actually started writing the code for passing in CompletionContext but it didn’t feel right. I will now consider it approved :-). It should be okay to pass the opened name, and then for failures, which is what I am interested in handling, implement my own get-normalized-name function.

As for #2, I was only trying to recreate the logic from SimRep sample. It is lumping together the regular create with IRP_MJ_NETWORK_QUERY_OPEN by handling them in the same mini-filter callback. The latter is “disallowed” if it is determined that the request needs to be reparsed, in order to have the I/O manager reissue the request as a regular create that can be reparsed. At least, that is my understanding.

Having done a tiny bit more reading, the current recommendation seems to be to disallow every IRP_MJ_NETWORK_QUERY_OPEN as this is the new “default” in Vista(+), because some pre-installed driver does just that. This is of course the easiest solution by far and I will try it.

Thanks!

Regards,
Otto

4

> Thank you for the tip regarding #1. I had actually started writing the code for passing in CompletionContext but it didn’t feel right. I will now consider it approved :-). It should be okay to pass the opened name, and then for failures, which is what I am interested in handling, implement my own get-normalized-name function.

Do you require the normalized name for the reparse itself or for some comparison?

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

5

Hi Dejan,

The driver needs the normalized name so it can look it up in its configuration. The driver will then know if it should reparse/where the reparse should go.

Thanks,
Otto

6

Dejan has a good point. However, please be aware that if you only need the
name for files that do not exist (since the FS returned
STATUS_OBJECT_PATH_NOT_FOUND or STATUS_OBJECT_NAME_NOT_FOUND) then the
normalized name will still not be better than the opened name for the part
of the path that doesn’t exist (because FltMgr will get the opened name and
then proceed to normalize it and any portion of the path that doesn’t exist
will be left as is).

Thanks,
Alex.

7

Buuuut, if the file does not exist, you can only get the available path as normalized.
Also, note that there are cases where you cannot get normalized names (such as paths without traverse privilege).

xxxxx@hotmail.com wrote:

Hi Dejan,

The driver needs the normalized name so it can look it up in its configuration. The driver will then know if it should reparse/where the reparse should go.

Thanks,
Otto

NTFSD is sponsored by OSR

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

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

8

Regarding paths, I was planning to normalize the path myself since all I have is a failed create request and no FILE_OBJECT, so FltMgr cannot help me here? It won’t be a problem that the latter part of the path cannot be normalized. It is expected.

The problem of paths without traverse privileges was something I had in the back of my mind, and this may become a problem. I will see if I can think of something.

Many thanks