A file object returned to a directory or to a file ?

NTFSD
1

Hi all , i have written a function to find out if a file object is related to a directory or to a file . here’s my code :

BOOLEAN FuncQueryFileInformation( PDEVICE_OBJECT DeviceObject,
PFILE_OBJECT FileObject,
PFILE_STANDARD_INFORMATION FileInformation, ULONG FileInformationLength )
{
PIRP irp;
KEVENT event;
IO_STATUS_BLOCK IoStatusBlock;
PIO_STACK_LOCATION ioStackLocation;

DbgPrint((“Getting file information for (%x)\n”, FileObject));

KeInitializeEvent(&event, SynchronizationEvent, FALSE);

irp = IoAllocateIrp(DeviceObject->StackSize, FALSE);

if (!irp) {

return FALSE;
}

irp->AssociatedIrp.SystemBuffer = FileInformation;
irp->UserEvent = &event;
irp->UserIosb = &IoStatusBlock;
irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = FileObject;
irp->RequestorMode = KernelMode;
irp->Flags = 0;

ioStackLocation = IoGetNextIrpStackLocation(irp);
ioStackLocation->MajorFunction = IRP_MJ_QUERY_INFORMATION;
ioStackLocation->DeviceObject = DeviceObject;
ioStackLocation->FileObject = FileObject;
ioStackLocation->Parameters.QueryFile.Length = FileInformationLength;
ioStackLocation->Parameters.QueryFile.FileInformationClass = FileStandardInformation ;

IoSetCompletionRoutine(irp, FuncQueryFileInformationComplete, 0, TRUE, TRUE, TRUE);

(void) IoCallDriver(DeviceObject, irp);

KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);

return NT_SUCCESS( IoStatusBlock.Status );
}

NTSTATUS FuncQueryFileInformationComplete(PDEVICE_OBJECT DeviceObject,
PIRP Irp,
PVOID Context)
{
*Irp->UserIosb = Irp->IoStatus;

if( !NT_SUCCESS(Irp->IoStatus.Status) ) {

DbgPrint((" ERROR ON IRP: %x\n", Irp->IoStatus.Status ));
}

KeSetEvent(Irp->UserEvent, 0, FALSE);

IoFreeIrp(Irp);

return STATUS_MORE_PROCESSING_REQUIRED;
}

what’s wrong with these routines ? why they allways returns “STATUS_INVALID_PARAMETER” ?

thanks.

2

As a minifilter, you can simply use:

NTSTATUS FltIsDirectory( __in PFILE_OBJECT FileObject, __in PFLT_INSTANCE Instance, __out PBOOLEAN IsDirectory );

http://msdn.microsoft.com/en-us/library/aa488639.aspx

Also the information is cached, so queries are potentially also more efficient.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

3

Wonderful ! that’s good , but as i want to call “FltIsDirectory” in a dispatch routine for IRP_MJ_CREATE , dose it cause a loop to my device again ?
I have installed an IFS kit wich only supports driver development for the following Windows operating systems:

Microsoft? Windows? Server 2003 (32-bit and 64-bit environments)
Microsoft Windows XP (32-bit and 64-bit environments)
Microsoft Windows 2000
Microsoft Windows Millennium Edition (Windows Me)
and it dosen’t contained the “Fltxxx” routines.

Regards,
Neda.

4

> KeInitializeEvent(&event, SynchronizationEvent, FALSE);

NotificationEvent is better for this.

irp->AssociatedIrp.SystemBuffer = FileInformation;
irp->UserEvent = &event;

Usually, event is passed to the completion routine as completion context. Touching ->UserEvent is not a good idea, this is IO manager’s field and not yours.

irp->UserIosb = &IoStatusBlock;

Usually, the completion routine does not do IoFreeIrp, so, the caller code is - wait, then analyze Irp->IoStatus, then IoFreeIrp.

irp->Tail.Overlay.Thread = PsGetCurrentThread();

This is correct and is a must, for instance, for disk storage stack IRPs.

irp->Tail.Overlay.OriginalFileObject = FileObject;

Never ever do this, since this field is IO manager’s one and not yours.

irp->Flags = 0;

Never ever do this, since this field is IO manager’s one and not yours.

ioStackLocation->DeviceObject = DeviceObject;

Do not do this, IoCallDriver does this properly.

KeWaitForSingleObject(&event, Executive, KernelMode, TRUE, 0);

…and after this, analyze Irp->IoStatus.Status and call IoFreeIrp

*Irp->UserIosb = Irp->IoStatus;

No need in this.

KeSetEvent(Irp->UserEvent, 0, FALSE);

Usually, event is completion context and not ->UserEvent

IoFreeIrp(Irp);

No need in this.

Also check once more that Parameters.QueryFile.Length is filled properly.

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

5

You should switch to the modern WDK. The IFS kit is years out of date now and predates general availability of filter manager IIRC.

? S

-----Original Message-----
From: xxxxx@yahoo.com
Sent: Sunday, December 21, 2008 00:17
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] A file object returned to a directory or to a file ?

Wonderful ! that’s good , but as i want to call “FltIsDirectory” in a dispatch routine for IRP_MJ_CREATE , dose it cause a loop to my device again ?
I have installed an IFS kit wich only supports driver development for the following Windows operating systems:

Microsoft? Windows? Server 2003 (32-bit and 64-bit environments)
Microsoft Windows XP (32-bit and 64-bit environments)
Microsoft Windows 2000
Microsoft Windows Millennium Edition (Windows Me)
and it dosen’t contained the “Fltxxx” routines.

Regards,
Neda.

—
NTFSD is sponsored by OSR

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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

>You should switch to the modern WDK. The IFS kit is years out of date now and predates general

availability of filter manager IIRC.

FltMgr is IIRC from 2003 SP1/XP SP2 up, so, 3790.1830’s contemporary IFS kit should have FltMgr.

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

7

Your memories are “well smoked”; indeed 3790.1830 IFS has FltMgr, I’ve used
that for a couple of years :slight_smile:

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
>You should switch to the modern WDK. The IFS kit is years out of date now
>and predates general
>availability of filter manager IIRC.

FltMgr is IIRC from 2003 SP1/XP SP2 up, so, 3790.1830’s contemporary IFS kit
should have FltMgr.

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

8

Sarosh,

Does it properly invalidate the cache in the case of a supersede? I
haven’t checked it in years, but there was an esoteric option to
supersede a file into a directory at one point in time.

Tony
OSR
“Twisted keeper of ways to torture file systems, filter drivers and
those that develop them.”

9

Neda,

FltIsDirectory needs an opened file object. Hence it cannot be called using the yet unopened file object that you have in the pre-create callback. In the pre-create callback, you can only determine whether the user is trying to open a file or a directory using the parameters that the user supplied.

In the post-create callback, if the create succeeded, after the file object has been opened, you can use FltIsDirectory to ask the file system if the file object represents a file or a directory.

Alternatively, you can query the opened name in the pre-create callback and then issue your own create using FltCreateFile to obtain a file object and then use FltIsDirectory on that opened file object to determine if the file object represents a file or a directory. Note that this also does not guarantee that this information will not change by the time you send down the original create for which you are processing the pre-create. For example, before you let the create pass down to the file system another thread could have deleted the file and created a directory in its place or vice-versa.

Tony,

I wll check on this esoteric option to supersede a file into a directory.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

10

Tony,

We checked but found no file system support for superseding a file into
a directory. If you can try and recall the exact scenario, we would be
happy to investigate.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

11

Sarosh,

Thanks for your comments, but

FltIsDirectory needs an opened file object. Hence it cannot be called using the
yet unopened file object that you have in the pre-create callback. In the
pre-create callback, you can only determine whether the user is trying to open a
file or a directory using the parameters that the user supplied.
what do you mean by checking the “parameters that the user supplied.” ?

Regards,
Neda

12

>what do you mean by checking the “parameters that the user supplied.” ?

FILE_NON_DIRECTORY_FILE and FILE_DIRECTORY_FILE flags. You can check for these flag in the Pre-create callback to determine whether the requestor has specifically requested for a file open or a directory open. But these flags do not indicate that the path represents a file/ directory.

So, if a user specifies FILE_NON_DIRECTORY_FILE for a path that is a directory; the call will fail.

Regards,
Ayush Gupta

13

Thanks Ayush for your feedback.

FILE_NON_DIRECTORY_FILE and FILE_DIRECTORY_FILE flags.
…
So, if a user specifies FILE_NON_DIRECTORY_FILE for a path that is a directory;
the call will fail.

So , you mean that these falgs are trustful because an invalid flaf cause the IRP to be failed, am I right?

Best wishes,
Neda

happy new year , wish you all happiness…