I’m building a HSM filter where we have data stored off line and at the users behest we reload files from off line store. I want however for all this to be transparent to the user so when he looks at the explorer or Dos for a files size or attributes he sees the information as if it were there.
I’ve tried altering the information in POST IRP_MJ_QUERY_INFORMATION callback, but it does not seem to do anything (yes I called the dirtydata routine).
What does seem to be the case is that explorer et. al get this information from someplace else as they sure don’t call the above IRP for it.
Where do they get it, how can I affect it?
Thanks
Larry
You can change e.g. date&time in post-operation IRP_MJ_QUERY_INFORMATION
callback, where user-buffer for minifilter is:
PUCHAR pUserBuffer = (PUCHAR)
Data->Iopb->Parameters.DirectoryControl.QueryDirectory.DirectoryBuffer;
if you don’t change buffer’s size (to add new entries) then it’s not
necessary to call FltSetCallbackDataDirty routine. When you remove the
entries, it’s not still needed to change buffer (total buffer’s size is
returned in pIrp->Status->Information). If you want to add new entries to
the buffer, you’ll need to return your own entries in pre-operation
IRP_MJ_QUERY_INFORMATION callback.
wrote in message news:xxxxx@ntfsd…
> I’m building a HSM filter where we have data stored off line and at the
> users behest we reload files from off line store. I want however for all
> this to be transparent to the user so when he looks at the explorer or Dos
> for a files size or attributes he sees the information as if it were
> there.
>
> I’ve tried altering the information in POST IRP_MJ_QUERY_INFORMATION
> callback, but it does not seem to do anything (yes I called the dirtydata
> routine).
>
> What does seem to be the case is that explorer et. al get this information
> from someplace else as they sure don’t call the above IRP for it.
>
> Where do they get it, how can I affect it?
>
> Thanks
>
> Larry
>
I should add that we have placeholder 0 length files with metadata stored in an alternate data stream for our files.
The thing is, that my IRP_MJ_QUERY_INFORMATION callback are simply not called when a directory is browsed in the explorer, nor is it called when a Dir command is issued in a command shell.
I do see traffic to the callbacks, but the files it is querying for are an odd assortment. Nothing that suggests it is systematically examining of files that are in the directory of interest.
So the question remains , where does this information get stashed by the system ?
Larry
I still don’t understand what you mean 
All queries (FindFirst/FindNext) from explorer or dir command are translated
to IRP_MJ_QUERY_INFORMATION, which can be called once/twice/… many times,
according to input buffer size. If the buffer size is not large enough to
return all entries, you may see another IRP_MJ_QUERY_INFORMATION call. Query
routine doesnt use standard ?, * chars, but DOS_STAR/DOS_QM/DOS_DOT chars
(see ntifs.h). The returned files are “unsorted” – it depends on root table
how they are stored on the disk.
wrote in message news:xxxxx@ntfsd…
>I should add that we have placeholder 0 length files with metadata stored
>in an alternate data stream for our files.
>
> The thing is, that my IRP_MJ_QUERY_INFORMATION callback are simply not
> called when a directory is browsed in the explorer, nor is it called when
> a Dir command is issued in a command shell.
>
> I do see traffic to the callbacks, but the files it is querying for are an
> odd assortment. Nothing that suggests it is systematically examining of
> files that are in the directory of interest.
>
>
> So the question remains , where does this information get stashed by the
> system ?
>
> Larry
>