hi all,
I have a minifilter which calls FltGetFileNameInformation then FltParseFileNameInformation
and at last FltCreateFileEx, all in PRE_CREATE.
The problem is when I try to save as applications give me access denied error for the requested file, while the empty file is created.
I commented the rest of the code and now I only have pre_create containing what I explained above.
if any of FltGetFileNameInformation or FltCreateFileEx get commented, it would remove the error. Is something wrong about calling these in pre-create which I am not aware of?
parameters :
FltGetFileNameInformation(data,
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_FILESYSTEM_ONLY,
nameInfo);
FltCreateFileEx(FltObjects->Filter,
FltObjects->Instance,
&fileHandle,
&fileObject,
Data->Iopb->Parameters.Create.SecurityContext->DesiredAccess,
&objectAttributes,
&ioStatus,
&Data->Iopb->Parameters.Create.AllocationSize,
Data->Iopb->Parameters.Create.FileAttributes,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
FILE_OPEN,
Data->Iopb->Parameters.Create.Options,
Data->Iopb->Parameters.Create.EaBuffer,
Data->Iopb->Parameters.Create.EaLength,
0);
I checked FltCreateFileEx for returned status. It returns multiple STATUS_OBJECT_NAME_NOT_FOUND first then it keeps returning STATUS_DELETE_PENDING for my target file.
Any comment?
>if any of FltGetFileNameInformation or FltCreateFileEx get commented
replace with
if FltCreateFileEx get commented
Your question is way to open ended.
What you’re trying to do definitely works. However, creates can have side
effects so, yes, opening the file yourself can mess with the calling
application. You need to look carefully at the operations and see what’s
going on. Does the user open have the delete on close bit set? Also check
the ACL on the newly created file and make sure you haven’t messed something
up.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
if any of FltGetFileNameInformation or FltCreateFileEx get commented
replace with
if FltCreateFileEx get commented
Thanks scott
Your question is way to open ended.
To me it is way more restricted!! It seems that I am not understanding something correctly!
The whole code and callbacks are commented and I only have those 3 mentioned function calls. (besides driverEntry and load-unload handlers)
yes, opening the file yourself can mess with the calling application.
I am not opening file instead of FS. I am calling FltCreateFileEx using FILE_OPEN as create disposition. Also the create always fails for that specific file. I am stating this because I feel you think I am opening the file and completing the operation myself.
There is also no case in which I return any return value other than FLT_PREOP_SUCCESS_NO_CALLBACK.
I see no where which I can interfere with FS really! could you please be more specific. (Well if you still consider my case open-ended you can’t)
For now, my only guess is I am doing something wrong with FltCreateFileEx performed on other files than the target file. i.e. directory-volume opens which might successfully be created.
objectAttributes contains what ???
it might be like : InitializeObjectAttributes(&oa,
Name,
OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE,
Handle,
NULL);
since it is not necessary to use thease Data->Iopb->Parameters.Create.EaBuffer,Data->Iopb->Parameters.Create.EaLength, here.
./nT
Can you explain at a higher level what it is you’re trying to do? I’m sorry
but there just isn’t enough detail to grab onto here to even begin to give
you an answer. There’s lots of reasons why opening a file might fail.
Best I can do at this point is to say the following:
-
If you’re in PreCreate and you’re trying to open a file that is being
created then I would expect you to get STATUS_OBJECT_NAME_NOT_FOUND (it
hasn’t been created yet…).
-
You’re reflecting the caller’s create options into the lower open
(Data->Iopb->Parameters.Create.Options). If the file exists and
FILE_DELETE_ON_CLOSE is set, you’re going to prematurely set the file as
delete pending.
Does this also happen on FAT? If yes, I *highly* recommend building your own
copy of FASTFAT and running it on your target machine. This will let you set
breakpoints in the lower file system and step through the code. This can
help build a better understanding of what’s going on (especially when things
don’t work).
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
Thanks scott
Your question is way to open ended.
To me it is way more restricted!! It seems that I am not understanding
something correctly!
The whole code and callbacks are commented and I only have those 3 mentioned
function calls. (besides driverEntry and load-unload handlers)
yes, opening the file yourself can mess with the calling application.
I am not opening file instead of FS. I am calling FltCreateFileEx using
FILE_OPEN as create disposition. Also the create always fails for that
specific file. I am stating this because I feel you think I am opening the
file and completing the operation myself.
There is also no case in which I return any return value other than
FLT_PREOP_SUCCESS_NO_CALLBACK.
I see no where which I can interfere with FS really! could you please be
more specific. (Well if you still consider my case open-ended you can’t)
For now, my only guess is I am doing something wrong with FltCreateFileEx
performed on other files than the target file. i.e. directory-volume opens
which might successfully be created.
>>objectAttributes contains what ???
>it might be like : InitializeObjectAttributes(&oa,
> Name,
> OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE,
> Handle,
> NULL);
yes, it does.
>1. If you’re in PreCreate and you’re trying to open a file that is being
>created then I would expect you to get STATUS_OBJECT_NAME_NOT_FOUND (it
>hasn’t been created yet…).
yes it returns STATUS_OBJECT_NAME_NOT_FOUND first but STATUS_DELETE_PENDING after that.
>2. You’re reflecting the caller’s create options into the lower open
>(Data->Iopb->Parameters.Create.Options). If the file exists and
>FILE_DELETE_ON_CLOSE is set, you’re going to prematurely set the file as
>delete pending.
I tried having FILE_DELETE_ON_CLOSE removed. even that did not help.
I will try what you suggested. Thanks.
I found the problem couple of days ago.
The problem was the handle to some files remaining opened.
Nice! Glad to hear you’re unblocked and on to the next thing.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
I found the problem couple of days ago.
The problem was the handle to some files remaining opened.
Thanks Scott.
Can you guess what could keep a file from being opened successfully when I had its handle opened using FILE_OPEN disposition?
I’ve read about conflicting share access and desired access and tested different access values with no luck already