Detect directory creation?

NTFSD
1

Dumb question for Thursday…

How does one detect the creation of a new directory? I chase through the
various structures and find several flags that may indicate ‘create’ vs.
‘open existing’ but none of them ever react in response to a WIN32
CreateDirectory().

I see all sorts of access to existing directories.

Also, is there a foolproof way to determine ‘this is a write operation’
for any file create situation? Generally speaking, my filter doesn’t
care about read activity but it does care about the creation of new
things - directories, files, registry keys, etc.

Some of the stuff I’ve attempted to check…

FLT_PREOP_CALLBACK_STATUS PreCreateCallback (
PFLT_CALLBACK_DATA Data,
PCFLT_RELATED_OBJECTS FltObjects,
PVOID *CompletionContext)
{
PFLT_IO_PARAMETER_BLOCK IopbPtr = Data->Iopb;
ULONG IrpFlags = IopbPtr->IrpFlags;
PFILE_OBJECT TargetFileObjectPtr = IopbPtr->TargetFileObject;

PFLT_PARAMETERS Parameters = &IopbPtr->Parameters;
PIO_SECURITY_CONTEXT SecurityContext =
Parameters->Create.SecurityContext;
ACCESS_MASK DesiredAccess = SecurityContext->DesiredAccess;

CreateOptions = Parameters->Create.Options & 0x00FFFFFF;
ThisIsADirectoryOperation = ((CreateOptions & FILE_DIRECTORY_FILE)
!= 0);

[or FltIsDirectory(…, &ThisIsADirectoryOperation)]

[followed by a test open of the file to see if it really is a directory]

Regards,
Mickey.

2

There’s no way to know if it’s a directory until it’s open. So move your
tests to post-create and you’ll have better luck. FltIsDirectory() works
nicely.

The alternative is to use FltCreateFile() yourself in your pre-create to see
if it exists and/or is a directory.

Write operations are fairly easy to detect in pre-create:

DesiredAccess =
Data->Iopb->Parameters.Create.SecurityContext->DesiredAccess;
bWriteOperation = FlagOn( DesiredAccess, DELETE | FILE_WRITE_DATA |
FILE_APPEND_DATA );

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey Lane
Sent: Thursday, August 18, 2005 1:01 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Detect directory creation?

Dumb question for Thursday…

How does one detect the creation of a new directory? I chase through the
various structures and find several flags that may indicate ‘create’ vs.
‘open existing’ but none of them ever react in response to a WIN32
CreateDirectory().

I see all sorts of access to existing directories.

Also, is there a foolproof way to determine ‘this is a write operation’
for any file create situation? Generally speaking, my filter doesn’t
care about read activity but it does care about the creation of new
things - directories, files, registry keys, etc.

Some of the stuff I’ve attempted to check…

FLT_PREOP_CALLBACK_STATUS PreCreateCallback (
PFLT_CALLBACK_DATA Data,
PCFLT_RELATED_OBJECTS FltObjects,
PVOID *CompletionContext)
{
PFLT_IO_PARAMETER_BLOCK IopbPtr = Data->Iopb;
ULONG IrpFlags = IopbPtr->IrpFlags;
PFILE_OBJECT TargetFileObjectPtr = IopbPtr->TargetFileObject;

PFLT_PARAMETERS Parameters = &IopbPtr->Parameters;
PIO_SECURITY_CONTEXT SecurityContext =
Parameters->Create.SecurityContext;
ACCESS_MASK DesiredAccess = SecurityContext->DesiredAccess;

CreateOptions = Parameters->Create.Options & 0x00FFFFFF;
ThisIsADirectoryOperation = ((CreateOptions & FILE_DIRECTORY_FILE)
!= 0);

[or FltIsDirectory(…, &ThisIsADirectoryOperation)]

[followed by a test open of the file to see if it really is a directory]

Regards,
Mickey.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

In postCreateCallback (if that is what it is called)
look at the disposition. If you have to know in
preCreate, it’s much more complicated.

— Mickey Lane wrote:

> Dumb question for Thursday…
>
> How does one detect the creation of a new directory?
> I chase through the
> various structures and find several flags that may
> indicate ‘create’ vs.
> ‘open existing’ but none of them ever react in
> response to a WIN32
> CreateDirectory().
>
> I see all sorts of access to existing directories.
>
> Also, is there a foolproof way to determine ‘this is
> a write operation’
> for any file create situation? Generally speaking,
> my filter doesn’t
> care about read activity but it does care about the
> creation of new
> things - directories, files, registry keys, etc.
>
> Some of the stuff I’ve attempted to check…
>
> FLT_PREOP_CALLBACK_STATUS PreCreateCallback (
> PFLT_CALLBACK_DATA Data,
> PCFLT_RELATED_OBJECTS FltObjects,
> PVOID *CompletionContext)
> {
> PFLT_IO_PARAMETER_BLOCK IopbPtr = Data->Iopb;
> ULONG IrpFlags = IopbPtr->IrpFlags;
> PFILE_OBJECT TargetFileObjectPtr =
> IopbPtr->TargetFileObject;
>
> PFLT_PARAMETERS Parameters =
> &IopbPtr->Parameters;
> PIO_SECURITY_CONTEXT SecurityContext =
> Parameters->Create.SecurityContext;
> ACCESS_MASK DesiredAccess =
> SecurityContext->DesiredAccess;
>
> CreateOptions = Parameters->Create.Options &
> 0x00FFFFFF;
> ThisIsADirectoryOperation = ((CreateOptions &
> FILE_DIRECTORY_FILE)
> != 0);
>
> [or FltIsDirectory(…,
> &ThisIsADirectoryOperation)]
>
> [followed by a test open of the file to see if
> it really is a directory]
>
> Regards,
> Mickey.
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

4

Hmm directory creation … well okay afaik in this case the
FILE_DIRECTORY_FILE must be set in IrpSp->Parameters.Create.FileAttributes
to say the thing to create is a directory… so now its down to the
IrpSp->Parameters.Create.Options as to whether this operation might create a
thing; see ifs kit docs.

“Mickey Lane” wrote in message news:xxxxx@ntfsd…
> Dumb question for Thursday…
>
> How does one detect the creation of a new directory? I chase through the
> various structures and find several flags that may indicate ‘create’ vs.
> ‘open existing’ but none of them ever react in response to a WIN32
> CreateDirectory().
>
> I see all sorts of access to existing directories.
>
> Also, is there a foolproof way to determine ‘this is a write operation’
> for any file create situation? Generally speaking, my filter doesn’t care
> about read activity but it does care about the creation of new things -
> directories, files, registry keys, etc.
>
> Some of the stuff I’ve attempted to check…
>
> FLT_PREOP_CALLBACK_STATUS PreCreateCallback (
> PFLT_CALLBACK_DATA Data,
> PCFLT_RELATED_OBJECTS FltObjects,
> PVOID *CompletionContext)
> {
> PFLT_IO_PARAMETER_BLOCK IopbPtr = Data->Iopb;
> ULONG IrpFlags = IopbPtr->IrpFlags;
> PFILE_OBJECT TargetFileObjectPtr = IopbPtr->TargetFileObject;
>
> PFLT_PARAMETERS Parameters = &IopbPtr->Parameters;
> PIO_SECURITY_CONTEXT SecurityContext =
> Parameters->Create.SecurityContext;
> ACCESS_MASK DesiredAccess = SecurityContext->DesiredAccess;
>
> CreateOptions = Parameters->Create.Options & 0x00FFFFFF;
> ThisIsADirectoryOperation = ((CreateOptions & FILE_DIRECTORY_FILE) !=
> 0);
>
> [or FltIsDirectory(…, &ThisIsADirectoryOperation)]
>
> [followed by a test open of the file to see if it really is a
> directory]
>
> Regards,
> Mickey.
>
>

5

Lyndon J Clarke wrote:

Hmm directory creation … well okay afaik in this case the
FILE_DIRECTORY_FILE must be set in
IrpSp->Parameters.Create.FileAttributes
to say the thing to create is a directory…

That’s what this does I think

CreateOptions = Parameters->Create.Options & 0x00FFFFFF;
ThisIsADirectoryOperation = ((CreateOptions & FILE_DIRECTORY_FILE) != 0);
or…
FltIsDirectory(…, &ThisIsADirectoryOperation);

(BTW 0x00FFFFFF should be FILE_VALID_OPTION_FLAGS)

so now its down to the
IrpSp->Parameters.Create.Options as to whether this operation might
create a
thing; see ifs kit docs.

The only thing I see anywhere close is create disposition (the upper 8
bits) which is one of FILE_SUPERSEDE, FILE_OPEN, FILE_CREATE,
FILE_OPEN_IF, FILE_OVERWRITE, FILE_OVERWRITE_IF or
FILE_MAXIMUM_DISPOSITION. The docs say “CreateDisposition - Specifies
the action to perform if the file does or does not exist.
CreateDisposition can be one of the following values:”

I’ve been using these flags (incorrectly, I believe) to determine
read/write for non-directory files. They don’t seem to work on directory
files which is pretty much how I got on this subject.

Regards,
Mickey.

“Mickey Lane” wrote in message news:xxxxx@ntfsd…
>
>> Dumb question for Thursday…
>>
>> How does one detect the creation of a new directory? I chase through the
>> various structures and find several flags that may indicate ‘create’ vs.
>> ‘open existing’ but none of them ever react in response to a WIN32
>> CreateDirectory().
>>
>> I see all sorts of access to existing directories.
>>
>> Also, is there a foolproof way to determine ‘this is a write operation’
>> for any file create situation? Generally speaking, my filter doesn’t
>> care
>> about read activity but it does care about the creation of new things -
>> directories, files, registry keys, etc.
>>
>> Some of the stuff I’ve attempted to check…
>>
>> FLT_PREOP_CALLBACK_STATUS PreCreateCallback (
>> PFLT_CALLBACK_DATA Data,
>> PCFLT_RELATED_OBJECTS FltObjects,
>> PVOID *CompletionContext)
>> {
>> PFLT_IO_PARAMETER_BLOCK IopbPtr = Data->Iopb;
>> ULONG IrpFlags = IopbPtr->IrpFlags;
>> PFILE_OBJECT TargetFileObjectPtr = IopbPtr->TargetFileObject;
>>
>> PFLT_PARAMETERS Parameters = &IopbPtr->Parameters;
>> PIO_SECURITY_CONTEXT SecurityContext =
>> Parameters->Create.SecurityContext;
>> ACCESS_MASK DesiredAccess = SecurityContext->DesiredAccess;
>>
>> CreateOptions = Parameters->Create.Options & 0x00FFFFFF;
>> ThisIsADirectoryOperation = ((CreateOptions & FILE_DIRECTORY_FILE) !=
>> 0);
>>
>> [or FltIsDirectory(…, &ThisIsADirectoryOperation)]
>>
>> [followed by a test open of the file to see if it really is a
>> directory]
>>
>> Regards,
>> Mickey.
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@earthlink.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>