CreateFile user/kernel mode

I have noticed that in a mini filter’s Pre_Create code, that the values for CreateDisposition are different between FltCreateFile() and a user’s call to CreateFile().

Specifically, the open/create/overwite values do map between the two.

IF_EXIST? NO_EXIST USER KERNEL
fail create_new (1)CREATE_NEW (0x0002)FILE_CREATE
overwrite create_new (2)CREATE_ALWAYS (0x0005)FILE_OVERWRITE_IF
open fail (3)OPEN_EXISTING (0x0001)FILE_OPEN
open create_new (4)OPEN_ALWAYS (0x0003)FILE_OPEN_IF
overwite/trunc fail (5)TRUNCATE_EXISTING (0x0004)FILE_OVERWRITE

The values in () are the values from the header files. the user ones are decimal values and the Kernel ones are defined in hex but that does not matter as the range is 1-5.

The question I have is simple, does the minifilter have a way to identify if the caller that started the pre-create path is using kernel or user mode values? ie: a kernel mode 1 (FILE_OPEN) means open if it exists but, a 1 (CREATE_NEW) from user space means create a new file if it does not exist.

So…How does the minifilter tell if the call is from user or kernel??

Jerry

By the time things get to the mini-filter everything is expressed in
kernel terms. It is not up to you to deal with this, the OS does.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@gmail.com” wrote in message
news:xxxxx@ntfsd:

> I have noticed that in a mini filter’s Pre_Create code, that the values for CreateDisposition are different between FltCreateFile() and a user’s call to CreateFile().
>
> Specifically, the open/create/overwite values do map between the two.
>
> IF_EXIST? NO_EXIST USER KERNEL
> fail create_new (1)CREATE_NEW (0x0002)FILE_CREATE
> overwrite create_new (2)CREATE_ALWAYS (0x0005)FILE_OVERWRITE_IF
> open fail (3)OPEN_EXISTING (0x0001)FILE_OPEN
> open create_new (4)OPEN_ALWAYS (0x0003)FILE_OPEN_IF
> overwite/trunc fail (5)TRUNCATE_EXISTING (0x0004)FILE_OVERWRITE
>
> The values in () are the values from the header files. the user ones are decimal values and the Kernel ones are defined in hex but that does not matter as the range is 1-5.
>
> The question I have is simple, does the minifilter have a way to identify if the caller that started the pre-create path is using kernel or user mode values? ie: a kernel mode 1 (FILE_OPEN) means open if it exists but, a 1 (CREATE_NEW) from user space means create a new file if it does not exist.
>
> So…How does the minifilter tell if the call is from user or kernel??
>
> Jerry

Thx,

thats great.

Can i then assume, that the disposition flags are ‘one of’ and not a ‘combination of’ values?

I ask as the FltCreateFile states:“The value can be any of those described following”. and the user mode CreateFile states: “his parameter must be one of the following values, which cannot be combined:”

Jerry

The best way to check things like this is look at the IRP
http://msdn.microsoft.com/en-us/library/ff548630(VS.85).aspx since the
mini-filter just packages those parameters.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@gmail.com” wrote in message
news:xxxxx@ntfsd:

> Thx,
>
>
> thats great.
>
> Can i then assume, that the disposition flags are ‘one of’ and not a ‘combination of’ values?
>
> I ask as the FltCreateFile states:“The value can be any of those described following”. and the user mode CreateFile states: “his parameter must be one of the following values, which cannot be combined:”
>
>
> Jerry

Thanks,

One other question.

In xxxCreateFile() I see the Disposition option of FILE_SUPERSEDE.

How does it differ from FILE_OVERWRITE_IF ?

Jerry

Found the answer…

http://www.osronline.com/article.cfm?article=302

Jerry

From IoCreateFile documentation:

The Disposition value FILE_SUPERSEDE requires that the caller have
DELETE access to a existing file object. If so, a successful call to
IoCreateFile with FILE_SUPERSEDE on an existing file effectively deletes
that file, and then recreates it. This implies that, if the file has
already been opened by another thread, it opened the file by specifying
a ShareAccess parameter with the FILE_SHARE_DELETE flag set. Note that
this type of disposition is consistent with the POSIX style of
overwriting files.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@gmail.com” wrote in message
news:xxxxx@ntfsd:

> Thanks,
>
>
> One other question.
>
> In xxxCreateFile() I see the Disposition option of FILE_SUPERSEDE.
>
> How does it differ from FILE_OVERWRITE_IF ?
>
>
> Jerry

>is using kernel or user mode values?

You will never see user-mode values in the kernel. Translation is done in user-mode kernel32.dll.

And yes, the values are enum, not bitmask.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> In xxxCreateFile() I see the Disposition option of FILE_SUPERSEDE.

How does it differ from FILE_OVERWRITE_IF ?

IIRC one is delete+re-create, and another is truncate of data to zero.

One of these ways retains all file attributes except data, another re-creates them all.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com