Hey, I implemented a stream context where I store the file name in the Post-Create routine to be accessed by the other routines to retrieve the file name for logging purposes. My driver however is not a boot time driver. So when my driver starts there are a few items that I dont have a file name for because I dont have a context for those objects. I try to do use
FltGetFileNameInformation(Data, FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT, &nameInfo);
to get the file name for these ones I dont have a context for, but this fails a lot so I dont have a path for these objects. Is there any way that I would still be able to get the file name for these objects without a context? Any other ways to try and get the file name safely or should I just live with a few path names not being found? Thanks for the help.
There isn’t a way to retrieve all the opened FILE_OBJECTs for a volume, so
you’ll have to deal with them when you see them. What I would do in this
case would be to reference the FILE_OBJECT and query the name again using
FltGetFileNameInformation from a worker thread, which should work.
On the other hand I’d like to point out that storing the file name in a
stream context is not generally a good idea for a couple of reasons. First,
it doesn’t work well for hardlinks (since one stream might have different
names). Then it is complicated to keep in sync with the actual file name
since files get renamed.
FltMgr implements exactly what I think you want in its internal name cache,
so that if the name of the file doesn’t change it will just get it from the
cache (FLT_FILE_NAME_QUERY_DEFAULT specifies this behavior). In my opinion
you’d be better of using FltMgr’s cache.
Thanks,
Alex.
“FltMgr implements exactly what I think you want in its internal name cache, so that if the name of the file doesn’t change it will just get it from the cache (FLT_FILE_NAME_QUERY_DEFAULT specifies this behavior). In my opinion you’d be better of using FltMgr’s cache.”
If your talking about using FltGetFileNameInformation() then this wasnt working for me enough. It was failing too much. I need to be able to get the file name every time essentially because I have to do a comparison with a file name the user entered and I have to get it in the pre callback because I have a portion of code that the user can decide to deny these events from happening. The stream context was working well since I was able to get the file name from the create operation whether it changed in between is fine thats a separate case im handling.
Basically I want to be able to get the file name in every pre callback operation if thats possible and FltGetFileNameInformation() didnt give me a file name everytime and I thought that using the FILE_OBJECT was only valid in the create operation. Unless im wrong on this and I can get the file name every time from the FILE_OBJECT then please explain a little bit more of that for me. Thanks
“If your talking about using FltGetFileNameInformation() then this wasnt
working for me enough. It was failing too much.”
Interesting, for me FltGetFileNameInformation() has been failing just right.
Perhaps you got a damaged one ? 
Joking aside, FltGetFileNameInformation will definitely not work in all
cases for every preOp callback. There are certain operations where it’s not
safe to query the file name from the file system so
FltGetFileNameInformation() fails in those cases. Please search the
archives, this topic has been discussed many times.
In general it’s not a good idea to stop access to a file once it’s been in
use. For example, if an application has written some data and then you stop
access to the file so it can’t write anymore, the data in the file might be
inconsistent and you’ve basically cause data corruption. This is similar to
killing a process and that’s not guaranteed to leave files in a consistent
state either. An even worse idea is to arbitrarily allow some operations to
go through and block others (for example, if someone renames the file a lot
while writing to it so for some operations a rule is matched while for
others it isn’t). This is pretty much a guaranteed way to corrupt data.
Most minifilters take the approach that if access to a file should be
restricted then IRP_MJ_CREATE should be failed. If you missed the
IRP_MJ_CREATE then all bets are off.
Anyway, at this point you are trying to glue wings on a pig (see this
article http://www.osronline.com/downloads/pp_asking.pdf) and I think I need
to know more about you are actually trying to achieve before I can offer any
more advice.
Thanks,
Alex.