Problem with Timeout parameter of FltSendMessage

NTFSD
1

Hello all,

The timeout parameter of the FltSendMessage is not
behaving as I would expect. I’d like to know if this
is unique to me or if others are experiencing the same
thing.

The IFS Kit documentation states:

Timeout
Pointer to a timeout value that specifies the total
absolute or relative length of time, in units of 100
nanoseconds, for which the caller can be put into a
wait state until the message is received by the
user-mode application and until it receives a reply
(if one is expected). Set to NULL if the caller can be
put into a wait state indefinitely.

In my testing:

Timeout.HighPart == 0x01000000
Timeout.LowPart == 0

times out. I think this works out to about 228 years,
but it seemed shorter than that :wink:

However,

Timeout.HighPart == 0x02000000
Timeout.LowPart == 0

works correctly.

It looks a little like the HighPart and LowPart are
transposed.

Of course, my concern is that this is a bug. If I
hard code the large value, it will effectively become
infinite if the bug is fixed.

Thanks in advance,
Derek

Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

2

Delta times are negative. If you want a timeout of, say, 5 seconds, then it
should be:

Timeout.QuadPart = -50000000LL;

HTH,
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Derek Dickinson
Sent: Monday, October 10, 2005 10:06 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problem with Timeout parameter of FltSendMessage

Hello all,

The timeout parameter of the FltSendMessage is not
behaving as I would expect. I’d like to know if this
is unique to me or if others are experiencing the same
thing.

The IFS Kit documentation states:

Timeout
Pointer to a timeout value that specifies the total
absolute or relative length of time, in units of 100
nanoseconds, for which the caller can be put into a
wait state until the message is received by the
user-mode application and until it receives a reply
(if one is expected). Set to NULL if the caller can be
put into a wait state indefinitely.

In my testing:

Timeout.HighPart == 0x01000000
Timeout.LowPart == 0

times out. I think this works out to about 228 years,
but it seemed shorter than that :wink:

However,

Timeout.HighPart == 0x02000000
Timeout.LowPart == 0

works correctly.

It looks a little like the HighPart and LowPart are
transposed.

Of course, my concern is that this is a bug. If I
hard code the large value, it will effectively become
infinite if the bug is fixed.

Thanks in advance,
Derek

Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Thanks :slight_smile:

— Ken Cross wrote:

> Delta times are negative. If you want a timeout of,
> say, 5 seconds, then it
> should be:
>
> Timeout.QuadPart = -50000000LL;
>
> HTH,
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf
> Of Derek Dickinson
> Sent: Monday, October 10, 2005 10:06 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Problem with Timeout parameter of
> FltSendMessage
>
> Hello all,
>
> The timeout parameter of the FltSendMessage is not
> behaving as I would expect. I’d like to know if
> this
> is unique to me or if others are experiencing the
> same
> thing.
>
> The IFS Kit documentation states:
>
> Timeout
> Pointer to a timeout value that specifies the total
> absolute or relative length of time, in units of 100
> nanoseconds, for which the caller can be put into a
> wait state until the message is received by the
> user-mode application and until it receives a reply
> (if one is expected). Set to NULL if the caller can
> be
> put into a wait state indefinitely.
>
> —
>
> In my testing:
>
> Timeout.HighPart == 0x01000000
> Timeout.LowPart == 0
>
> times out. I think this works out to about 228
> years,
> but it seemed shorter than that :wink:
>
> However,
>
> Timeout.HighPart == 0x02000000
> Timeout.LowPart == 0
>
> works correctly.
>
> It looks a little like the HighPart and LowPart are
> transposed.
>
> Of course, my concern is that this is a bug. If I
> hard code the large value, it will effectively
> become
> infinite if the bug is fixed.
>
> Thanks in advance,
> Derek
>
>
>
>
>
> Yahoo! Music Unlimited
> Access over 1 million songs. Try it free.
> http://music.yahoo.com/unlimited/
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@comcast.net
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>


Yahoo! Mail - PC Magazine Editors’ Choice 2005
http://mail.yahoo.com