If I am accessing PFLT_CALLBACK_DATA Data->IoStatus.Information in the
context of IRP_MJ_QUERY_DIRECTORY what information is this supposed to
contain?
If I use the PFILE_BOTH_DIR_INFORMATION ->NextEntryOffset it does not match
up to IoStatus.Information. In single entry or added up over multple entries
in the query.
->Parameters.DirectoryControl.QueryDirectory.Length from the DDK “Length,
in bytes, of the buffer that the *QueryDirectory.DirectoryBuffer* member
points to.” But even under conversion it does not seem to add up correctly.
sizeof( PFILE_BOTH_DIR_INFORMATION )+ ( FILE_BOTH_DIR_INFORMATION)
->FileNameLength is sometimes off by 2 from Data->IoStatus.Information and
others not. I am not sure of the pattern. WCHAR is 2 but why does it
sometimes match and others it does not on the same entries?
I tried to use FIELD_OFFSET using ->ShortName and ->FileName thinking that
the memory locations could in a differnt part of the buffer and not
calculated in the manner I expected. No luck.
I have read that Data->IoStatus.Information is the length of the entry if
it is a single entry? I have read through the threads in the archives but
for some reason can not seem to figure out the pattern. What I am attempting
to do is remove a directory entry from the buffer but in order to do the
memcpy I obviously need to know where the entry starts and ends to be able
to remove it.
Any clarity on the situation would be greatly appriciated.
Jason
Since FastFat had a bug where it returned an incorrect
Data->IoStatus.Information field you should not rely on it.
It SHOULD be the size of the data returned (single or multiple
entries).
What you should do in the completion:
- In case that you need to copy the data back, copy the entire
length of the original buffer (QueryDirectory.Length) - In case that you need to parse the entries (assuming
Data->IoStatus.Status is a success code), you can assume that at least
one entry is present, thus the buffer is the first entry. The next entry
(if any) will be at Buffer + NextEntryOffset (DO NOT do this directly,
use
Buffer = (PVOID)((PCHAR)Buffer + Buffer->NextEntryOffset);
A common error is to use Buffer += Buffer->NextEntryOffset (this
would add sizeof(*Buffer)*Buffer->NextEntryOffset instead).
Continue the loop until NextEntryOffset is 0. (entry with
NextEntryOffset = 0 will be the last entry).
If you need to modify the returned buffer, for hiding files,
remember that you will sometimes need to reissue the call.
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Thank you Dejan, you have been very helpful on this subject and information
is hard to come by.
I am using the code in a minifilter, do you mean by reissue the call as in
build and send another IRP if no files are returned since IOStatus.Status is
already set to success and it can not be modified in a completion function?
And since I can not rely on IOStatus.information if I use
fltSetCallbackDataDirty() to handle the manipulation of this field will it
also fall prey to the fastat bug? Question here is should I try and correct
the bug manually or is that field ok to just leave as is.
Agian your knowledge has been invaluable, Thanks
Jason
On 10/24/05, Dejan Maksimovic wrote:
>
>
> Since FastFat had a bug where it returned an incorrect
> Data->IoStatus.Information field you should not rely on it.
> It SHOULD be the size of the data returned (single or multiple
> entries).
>
> What you should do in the completion:
> - In case that you need to copy the data back, copy the entire
> length of the original buffer (QueryDirectory.Length)
> - In case that you need to parse the entries (assuming
> Data->IoStatus.Status is a success code), you can assume that at least
> one entry is present, thus the buffer is the first entry. The next entry
> (if any) will be at Buffer + NextEntryOffset (DO NOT do this directly,
> use
> Buffer = (PVOID)((PCHAR)Buffer + Buffer->NextEntryOffset);
>
> A common error is to use Buffer += Buffer->NextEntryOffset (this
> would add sizeof(*Buffer)*Buffer->NextEntryOffset instead).
>
> Continue the loop until NextEntryOffset is 0. (entry with
> NextEntryOffset = 0 will be the last entry).
>
> If you need to modify the returned buffer, for hiding files,
> remember that you will sometimes need to reissue the call.
>
> –
> Kind regards, Dejan M.
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
> developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Jason,
I am using the code in a minifilter, do you mean by reissue the call
as in
build and send another IRP if no files are returned since
IOStatus.Status is
already set to success and it can not be modified in a completion
function?
There is a legacy to minifilter cheat sheet on Microsoft.com at:
In the legacy model you would:
- return STATUS_MORE_PROCESSING_REQUIRED from the completion
- in the dispatch routine wait on an event, set by the
completion routine - check the buffer, and if you need to hide all the files,
reissue the call - if you receive no more files at this step (after reissue)
you simply return that, otherwise “goto step 3”
The cheat sheet describes how this is done in the minifilter
world.
And since I can not rely on IOStatus.information if I use
fltSetCallbackDataDirty() to handle the manipulation of this field
will it
also fall prey to the fastat bug? Question here is should I try and
correct
the bug manually or is that field ok to just leave as is.
IoStatus is not connected with FltSetCallbackDataDirty, you can
modify this field without calling FSCDD, it’s an exception (check the
docs, for a more precise definition).
You should correct the Information field after processing the buffer
yourself, as you will know the correct size of the buffer in this case.
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Dejan Maksimovic wrote:
IoStatus is not connected with FltSetCallbackDataDirty, you can
modify this field without calling FSCDD, it’s an exception (check the
docs, for a more precise definition).
Hmm… are you sure about this? The docs seem pretty clear to me that
any modification to the structure requires calling that function.
Tony
A minifilter’s preoperation (PFLT_PRE_OPERATION_CALLBACK) or postoperation
(PFLT_POST_OPERATION_CALLBACK) callback routine can modify the contents of the
callback data (FLT_CALLBACK_DATA) structure for the operation. If it does, it must
then call
>>>>> FltSetCallbackDataDirty unless it has changed the contents of the
>>>>> callback data structure’s IoStatus field.
Tony Hoyle wrote:
Hmm… are you sure about this? The docs seem pretty clear to me that
any modification to the structure requires calling that function.
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Dejan Maksimovic wrote:
A minifilter’s preoperation (PFLT_PRE_OPERATION_CALLBACK) or postoperation
(PFLT_POST_OPERATION_CALLBACK) callback routine can modify the contents of the
callback data (FLT_CALLBACK_DATA) structure for the operation. If it does, it must
then call>>>>>>FltSetCallbackDataDirty unless it has changed the contents of the
>>>>>>callback data structure’s IoStatus field.
Interesting…
So you essentially never have to call that function, as long as you
change the IoStatus.
Tony
As long as you ONLY change the IoStatus field.
Interesting…
So you essentially never have to call that function, as long as you
change the IoStatus.
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Dejan Maksimovic wrote:
As long as you ONLY change the IoStatus field.
That’s not what it says though. It clearly states that modifying
IoStatus is exempts you from calling FltSetCallbackDataDirty:
“… it must then call FltSetCallbackDataDirty unless it has changed the
contents of the callback data structure’s IoStatus field.”
If it doesn’t mean that maybe it should be reworded… something like …
“A minifilter’s preoperation (PFLT_PRE_OPERATION_CALLBACK) or
postoperation (PFLT_POST_OPERATION_CALLBACK) callback routine can modify
the contents of the callback data (FLT_CALLBACK_DATA) structure for the
operation. If it modifies any field other than IoStatus it must call
FltSetCallbackDataDirty”
It’s worth some experminentation to see which is really meant.
Tony
Yes it sounds that way, but this most probably is not the case. Can someone from
MS clear this?
Tony Hoyle wrote:
Dejan Maksimovic wrote:
> As long as you ONLY change the IoStatus field.
>
>
That’s not what it says though. It clearly states that modifying
IoStatus is exempts you from calling FltSetCallbackDataDirty:“… it must then call FltSetCallbackDataDirty unless it has changed the
contents of the callback data structure’s IoStatus field.”If it doesn’t mean that maybe it should be reworded… something like …
“A minifilter’s preoperation (PFLT_PRE_OPERATION_CALLBACK) or
postoperation (PFLT_POST_OPERATION_CALLBACK) callback routine can modify
the contents of the callback data (FLT_CALLBACK_DATA) structure for the
operation. If it modifies any field other than IoStatus it must call
FltSetCallbackDataDirty”It’s worth some experminentation to see which is really meant.
Tony
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Dejan’s original definition is correct. If ALL you do is modify the
status field, you do not need to call FltSetCallbackDataDirty. If you
modify any other field (with or without modifying the status field) you
must call FltSetCallbackDataDirty. We will update the documentation to
be clearer.
It probably would help to explain why we have this concept of marking
the CBD (callback data) dirty. This is an optimization to save us
copying parameters back to the IRP from the CBD. We figured if we could
save a few cycles by having you tell us when you changed something, it
would help. Marking the CBD structure dirty when nothing has changed
does not hurt anything, it simply causes filter manager to spend a few
extra cycles coping the parameters back to the IRP. If you don’t mark
it dirty when you did change something then that information will be
lost. We always copy the status field so it doesn’t matter if you mark
it in this situation.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Tuesday, October 25, 2005 1:11 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Data->IoStatus.Information
Yes it sounds that way, but this most probably is not the case. Can
someone from
MS clear this?
Tony Hoyle wrote:
Dejan Maksimovic wrote:
> As long as you ONLY change the IoStatus field.
>
>
That’s not what it says though. It clearly states that modifying
IoStatus is exempts you from calling FltSetCallbackDataDirty:“… it must then call FltSetCallbackDataDirty unless it has changed
the
contents of the callback data structure’s IoStatus field.”If it doesn’t mean that maybe it should be reworded… something like
…
“A minifilter’s preoperation (PFLT_PRE_OPERATION_CALLBACK) or
postoperation (PFLT_POST_OPERATION_CALLBACK) callback routine can
modify
the contents of the callback data (FLT_CALLBACK_DATA) structure for
the
operation. If it modifies any field other than IoStatus it must call
FltSetCallbackDataDirty”It’s worth some experminentation to see which is really meant.
Tony
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com