Is there a way to tell on the post-op path of a minifilter for an
IRP_MJ_CREATE if an open/create is for a file or directory without making
any additional calls (ie just from the structures that are available in the
callback)? I’ve been looking through the docs and help and don’t see this
anywhere (so today I’m calling FltQueryInformationFile).
The SL_OPEN_TARGET_DIRECTORY flag would indicate a directory, but that
condition isn’t the typical case.
If the file size happened to be available too, that would be great. But so
far it looks like that’s not the case.
Is there a way to tell on the post-op path of a minifilter for an
IRP_MJ_CREATE if an open/create is for a file or directory without making
any additional calls (ie just from the structures that are available in the
callback)? I’ve been looking through the docs and help and don’t see this
anywhere (so today I’m calling FltQueryInformationFile).
In short, no. There is no way to be 1100% certain without asking the
file system. Of course there are some flags such as FILE_DIRECTORY_FILE
which may be set but they don’t have to be.
The easiest method is to query the file system. You can call
FltIsDirectory() as well and FM may be doing some caching which
eliminates the call into the file system but not absolutely sure on this
and there are some restrictions on this call, see the docs.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting www.KernelDrivers.com
866.263.9295
> Is there a way to tell on the post-op path of a minifilter for an
> IRP_MJ_CREATE if an open/create is for a file or directory without
> making any additional calls (ie just from the structures that are
available
> in the callback)?
In short, no. There is no way to be 100% certain without asking the
file system. Of course there are some flags such as FILE_DIRECTORY_FILE
which may be set but they don’t have to be.
The easiest method is to query the file system. You can call
FltIsDirectory() as well and FM may be doing some caching which
eliminates the call into the file system but not absolutely sure on
this and there are some restrictions on this call, see the docs.
Pete
Thanks Pete and Rod.
I’ve got a minispy-based filter that does very little processing, and it had
worked fine for a couple of years everywhere up until about a month ago.
I’m now getting reports of a few machine hangs so I’m trying to see if I can
remove any calls back into the system, and FltQueryInformationFile is one of
them (and recently called in a few more cases than before).
As a side note, does anyone know how Volume Shadow Copy is implemented at
the driver level? One thing that the hanging machines seem to have in
common is VSS (although I’ve got it running everywhere here without
problem).
Just odd that three or four customers are suddenly having the same issue (on
Win 2003) within the past month.
As previously advised, the best thing to do is grab a crash dump from a hung
system, a coffee (or beer, your choice), and start picking through threads
to figure out why the hang is occurring. From there you can start making
some theories as to what is causing the problem, otherwise it’s all just
wild guesses.
“Doug” wrote in message news:xxxxx@ntfsd… >> Doug wrote: >> > Is there a way to tell on the post-op path of a minifilter for an >> > IRP_MJ_CREATE if an open/create is for a file or directory without >> > making any additional calls (ie just from the structures that are > available >> > in the callback)? >> >> In short, no. There is no way to be 100% certain without asking the >> file system. Of course there are some flags such as FILE_DIRECTORY_FILE >> which may be set but they don’t have to be. >> >> The easiest method is to query the file system. You can call >> FltIsDirectory() as well and FM may be doing some caching which >> eliminates the call into the file system but not absolutely sure on >> this and there are some restrictions on this call, see the docs. >> >> Pete > > Thanks Pete and Rod. > > I’ve got a minispy-based filter that does very little processing, and it > had > worked fine for a couple of years everywhere up until about a month ago. > I’m now getting reports of a few machine hangs so I’m trying to see if I > can > remove any calls back into the system, and FltQueryInformationFile is one > of > them (and recently called in a few more cases than before). > > As a side note, does anyone know how Volume Shadow Copy is implemented at > the driver level? One thing that the hanging machines seem to have in > common is VSS (although I’ve got it running everywhere here without > problem). > > Just odd that three or four customers are suddenly having the same issue > (on > Win 2003) within the past month. > > Doug > > > >
If CreateOptions contained FILE_DIRECTORY_FILE or FILE_NON_DIRECTORY_FILE
then you can trust the flags. If it didn’t contain any of the two flags, you
must perform aditional query (FltIsDirectory, as Peter S. suggested)
Petr
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doug
Sent: Friday, October 16, 2009 4:23 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Noob question: File or directory?
Is there a way to tell on the post-op path of a minifilter for an
IRP_MJ_CREATE if an open/create is for a file or directory without making
any additional calls (ie just from the structures that are available in the
callback)? I’ve been looking through the docs and help and don’t see this
anywhere (so today I’m calling FltQueryInformationFile).
The SL_OPEN_TARGET_DIRECTORY flag would indicate a directory, but that
condition isn’t the typical case.
If the file size happened to be available too, that would be great. But so
far it looks like that’s not the case.
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