Weird behaviour of ObQueryNameString....

NTFSD
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
In my FSFD i use ObQueryNameString to obtain the file path from FileObject.
I just noticed this weird behaviur:

in a code like that in a WorkRoutine triggered by my filter (i just made a
simple snippet for you to check) :

VOID FsWorkRoutine (PVOID Context)
{
PFSWORK_ITEM FsWrkItem = (PFSWORK_ITEM)Context);
ULONG ReturnLength = 0;
NT_STATUS Status;
PVOID pucBuffer = NULL;

// query the needed size to allocate a buffer large enough
Status = ObQueryNameString
(FsWkrItem->FileObject,(POBJECT_NAME_INFORMATION)pucBuffer,0,&Length);

if ((NT_SUCCESS (Status) && (Status != STATUS_INFO_LENGTH_MISMATCH)
{
// allocate buffer of the returned Size
(…)
}

(…)
return;
}

As far as i understood from the DDK, ObQueryNameString should work this way
:
if i pass 0 as Length parameter, it should return the required size for the
buffer in the last parameter.
Now… in the code above, if Length is 0, it returns
STATUS_INFO_LENGTH_MISMATCH as expected but it *DOESN’T* update the
ReturnLength parameter.
The same code,allocating a buffer before,and passing the size (let’s say,
100), works as the DDK says (updated ReturnLength).
What’s weird is i use the same exact code in another part of the driver and
it works.

Btw, the fileobject comes from an IRP_MJ_CLEANUP. In the IRP_MJ_CLEANUP
dispatch i wait on an event that will be set by the workroutine before
completing the IRP,
so the fileobejct shouldn’t be invalidated yet when i’m in the workroutine
(there’s no completion routine set). And anyway, as i said, passing a
nonzero size works.

Any ideas ?

Thanks,
Valerio

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQCld2WGxr2U3nc5EEQIm3QCg2Bk/0iJrXf30znIjGTTpSj4qCi0AoPPX
7KfFKX9qX57B/visLL12tVtL
=63ne
-----END PGP SIGNATURE-----

2

Only paging I/O operations are allowed between cleanup and close inside
of a file system; there is no guarantee that once the IRP_MJ_CLEANUP has
been processed by the underlying file system that anything OTHER than a
paging I/O operation (read, write, and certain length management
operations) will work properly. That may or may not be your problem,
but it is worth noting that you shouldn’t expect to be able to call
ObQueryObjectNameString in such a case in any case.

Of course, if you observe this problem with FAT, you should just walk
through the logic in the debugger and see why you observe this behavior.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Valerino
Sent: Tuesday, February 10, 2004 5:40 PM
To: ntfsd redirect
Subject: [ntfsd] Weird behaviour of ObQueryNameString…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
In my FSFD i use ObQueryNameString to obtain the file path from
FileObject.
I just noticed this weird behaviur:

in a code like that in a WorkRoutine triggered by my filter (i just made
a simple snippet for you to check) :

VOID FsWorkRoutine (PVOID Context)
{
PFSWORK_ITEM FsWrkItem = (PFSWORK_ITEM)Context);
ULONG ReturnLength = 0;
NT_STATUS Status;
PVOID pucBuffer = NULL;

// query the needed size to allocate a buffer large enough
Status = ObQueryNameString
(FsWkrItem->FileObject,(POBJECT_NAME_INFORMATION)pucBuffer,0,&Length);

if ((NT_SUCCESS (Status) && (Status != STATUS_INFO_LENGTH_MISMATCH)
{
// allocate buffer of the returned Size
(…)
}

(…)
return;
}

As far as i understood from the DDK, ObQueryNameString should work this
way
:
if i pass 0 as Length parameter, it should return the required size for
the buffer in the last parameter.
Now… in the code above, if Length is 0, it returns
STATUS_INFO_LENGTH_MISMATCH as expected but it *DOESN’T* update the
ReturnLength parameter.
The same code,allocating a buffer before,and passing the size (let’s
say, 100), works as the DDK says (updated ReturnLength).
What’s weird is i use the same exact code in another part of the driver
and it works.

Btw, the fileobject comes from an IRP_MJ_CLEANUP. In the IRP_MJ_CLEANUP
dispatch i wait on an event that will be set by the workroutine before
completing the IRP, so the fileobejct shouldn’t be invalidated yet when
i’m in the workroutine (there’s no completion routine set). And anyway,
as i said, passing a nonzero size works.

Any ideas ?

Thanks,
Valerio

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQCld2WGxr2U3nc5EEQIm3QCg2Bk/0iJrXf30znIjGTTpSj4qCi0AoPPX
7KfFKX9qX57B/visLL12tVtL
=63ne
-----END PGP SIGNATURE-----

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

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

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tony,
the IRP_MJ_CLEANUP irp has not been processed yet by the FS(NTFS) on
that fileobject.
In my cleanup dispatch code, i do query the workitem, then i wait on
an event that will be set by the workroutine.
Only after the event has been set i call the underlying FS to
complete the IRP.

And anyway, if i do allocate a proper chunk of memory… say
pBuffer = ExAllocatePool (PagedPool,1024);
Status = ObQueryNameString
(FileObject,(POBJECT_NAME_INFORMATION)pBuffer,1024,&ReturnSize);
(…)
the query in that case works. Its that what puzzles me.

It’s not such a big problem for me to preallocate the buffer, i just
wanted to know why that behaviour differs from what the DDK says.
It’s really simple code, i don’t do anything weird. that query
request is issued at the beginning of the work routine, and the
cleanup dispatch code
just gets the file object from IrpSp and fire the workitem, then
after waiting for it to complete, IoSkipCurrentIrpStackLocation and
call the underlying FS.

Valerio

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Only paging I/O operations are allowed between cleanup and close
inside
of a file system; there is no guarantee that once the IRP_MJ_CLEANUP
has
been processed by the underlying file system that anything OTHER than
a
paging I/O operation (read, write, and certain length management
operations) will work properly. That may or may not be your problem,
but it is worth noting that you shouldn’t expect to be able to call
ObQueryObjectNameString in such a case in any case.

Of course, if you observe this problem with FAT, you should just walk
through the logic in the debugger and see why you observe this
behavior.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

- -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Valerino
Sent: Tuesday, February 10, 2004 5:40 PM
To: ntfsd redirect
Subject: [ntfsd] Weird behaviour of ObQueryNameString…

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
In my FSFD i use ObQueryNameString to obtain the file path from
FileObject.
I just noticed this weird behaviur:

in a code like that in a WorkRoutine triggered by my filter (i just made
a simple snippet for you to check) :

VOID FsWorkRoutine (PVOID Context)
{
PFSWORK_ITEM FsWrkItem = (PFSWORK_ITEM)Context);
ULONG ReturnLength = 0;
NT_STATUS Status;
PVOID pucBuffer = NULL;

// query the needed size to allocate a buffer large enough
Status = ObQueryNameString
(FsWkrItem->FileObject,(POBJECT_NAME_INFORMATION)pucBuffer,0,&Length);

if ((NT_SUCCESS (Status) && (Status != STATUS_INFO_LENGTH_MISMATCH)
{
// allocate buffer of the returned Size
(…)
}

(…)
return;
}

As far as i understood from the DDK, ObQueryNameString should work this
way
:
if i pass 0 as Length parameter, it should return the required size for
the buffer in the last parameter.
Now… in the code above, if Length is 0, it returns
STATUS_INFO_LENGTH_MISMATCH as expected but it DOESN’T update the
ReturnLength parameter.
The same code,allocating a buffer before,and passing the size (let’s
say, 100), works as the DDK says (updated ReturnLength).
What’s weird is i use the same exact code in another part of the driver
and it works.

Btw, the fileobject comes from an IRP_MJ_CLEANUP. In the IRP_MJ_CLEANUP
dispatch i wait on an event that will be set by the workroutine before
completing the IRP, so the fileobejct shouldn’t be invalidated yet when
i’m in the workroutine (there’s no completion routine set). And anyway,
as i said, passing a nonzero size works.

Any ideas ?

Thanks,
Valerio

- -----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQCld2WGxr2U3nc5EEQIm3QCg2Bk/0iJrXf30znIjGTTpSj4qCi0AoPPX
7KfFKX9qX57B/visLL12tVtL
=63ne
- -----END PGP SIGNATURE-----

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

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

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQCnl32Gxr2U3nc5EEQLCZQCg4yk/3VEEhpqApiMH4AaKtkhZRj8An24v
OGHtYzZ5vEquhbyQu3gB9gNY
=ZgLl
-----END PGP SIGNATURE-----

4

Is the file object in question a stream file object
(FO_STREAM_FILE_OBJECT set in the Flags field)?

Can you tell us which file system and OS version on which you are
observing this behavior?

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class in Boston, MA, March
29, 2004!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Valerino
Sent: Wednesday, February 11, 2004 3:21 AM
To: ntfsd redirect
Subject: Re:[ntfsd] Weird behaviour of ObQueryNameString…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tony,
the IRP_MJ_CLEANUP irp has not been processed yet by the FS(NTFS) on
that fileobject.
In my cleanup dispatch code, i do query the workitem, then i wait on
an event that will be set by the workroutine.
Only after the event has been set i call the underlying FS to
complete the IRP.

And anyway, if i do allocate a proper chunk of memory… say
pBuffer = ExAllocatePool (PagedPool,1024);
Status = ObQueryNameString
(FileObject,(POBJECT_NAME_INFORMATION)pBuffer,1024,&ReturnSize);
(…)
the query in that case works. Its that what puzzles me.

It’s not such a big problem for me to preallocate the buffer, i just
wanted to know why that behaviour differs from what the DDK says.
It’s really simple code, i don’t do anything weird. that query
request is issued at the beginning of the work routine, and the
cleanup dispatch code
just gets the file object from IrpSp and fire the workitem, then
after waiting for it to complete, IoSkipCurrentIrpStackLocation and
call the underlying FS.

Valerio

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Only paging I/O operations are allowed between cleanup and close
inside
of a file system; there is no guarantee that once the IRP_MJ_CLEANUP
has
been processed by the underlying file system that anything OTHER than
a
paging I/O operation (read, write, and certain length management
operations) will work properly. That may or may not be your problem,
but it is worth noting that you shouldn’t expect to be able to call
ObQueryObjectNameString in such a case in any case.

Of course, if you observe this problem with FAT, you should just walk
through the logic in the debugger and see why you observe this
behavior.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

- -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Valerino
Sent: Tuesday, February 10, 2004 5:40 PM
To: ntfsd redirect
Subject: [ntfsd] Weird behaviour of ObQueryNameString…

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
In my FSFD i use ObQueryNameString to obtain the file path from
FileObject.
I just noticed this weird behaviur:

in a code like that in a WorkRoutine triggered by my filter (i just made
a simple snippet for you to check) :

VOID FsWorkRoutine (PVOID Context)
{
PFSWORK_ITEM FsWrkItem = (PFSWORK_ITEM)Context);
ULONG ReturnLength = 0;
NT_STATUS Status;
PVOID pucBuffer = NULL;

// query the needed size to allocate a buffer large enough
Status = ObQueryNameString
(FsWkrItem->FileObject,(POBJECT_NAME_INFORMATION)pucBuffer,0,&Length);

if ((NT_SUCCESS (Status) && (Status != STATUS_INFO_LENGTH_MISMATCH)
{
// allocate buffer of the returned Size
(…)
}

(…)
return;
}

As far as i understood from the DDK, ObQueryNameString should work this
way
:
if i pass 0 as Length parameter, it should return the required size for
the buffer in the last parameter.
Now… in the code above, if Length is 0, it returns
STATUS_INFO_LENGTH_MISMATCH as expected but it DOESN’T update the
ReturnLength parameter.
The same code,allocating a buffer before,and passing the size (let’s
say, 100), works as the DDK says (updated ReturnLength).
What’s weird is i use the same exact code in another part of the driver
and it works.

Btw, the fileobject comes from an IRP_MJ_CLEANUP. In the IRP_MJ_CLEANUP
dispatch i wait on an event that will be set by the workroutine before
completing the IRP, so the fileobejct shouldn’t be invalidated yet when
i’m in the workroutine (there’s no completion routine set). And anyway,
as i said, passing a nonzero size works.

Any ideas ?

Thanks,
Valerio

- -----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQCld2WGxr2U3nc5EEQIm3QCg2Bk/0iJrXf30znIjGTTpSj4qCi0AoPPX
7KfFKX9qX57B/visLL12tVtL
=63ne
- -----END PGP SIGNATURE-----

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

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

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQCnl32Gxr2U3nc5EEQLCZQCg4yk/3VEEhpqApiMH4AaKtkhZRj8An24v
OGHtYzZ5vEquhbyQu3gB9gNY
=ZgLl
-----END PGP SIGNATURE-----

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

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

5

Ok, I remember I encountered this once as well and looked a bit into it. As
far as I recall,
ObQueryNameString , for object types which do have an QueryName method, will
lookup
the object header, object type, then the query name procedure. File objects
do have a special
query name procedure , a internal OS function called IopQueryName(). This
API is called with some
of the parameters passed to ObQueryNameString() , and Length is one of them.

The funny part is that this function , as one of the first things, checks
whatever the Length parameter is at
least greater than the size of a UNICODE_STRING, to accomodate the minimum
size of required for output,
as defined by OBJECT_NAME_INFO. If the size passed is less then this, then
the function bails with a
STATUS_INFO_LENGTH_MISMATCH, without updating the required length at all.

In other cases, ObQueryNameString works as expected, and documented. But not
in this case, and the implementation
flaw is in query name method for files. I wanted to report this, but i
forgot unfortunately.

Regards,
Dan Partelly, Microsoft MVP for Windows DDK

6

Technically speaking, it needs to be at least
sizeof(OBJECT_NAME_INFORMATION), since that is the fixed size portion of
the structure you are passing in to this call.

That it works with a zero length buffer at all actually surprises me,
and probably is what leads to the confusion here. However, note that
in general the interfaces require that the buffer you pass down must be
the size of the fixed portion of the structure.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class in Boston, MA, March
29, 2004!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Partelly
Sent: Wednesday, February 11, 2004 1:09 PM
To: ntfsd redirect
Subject: Re: [ntfsd] Weird behaviour of ObQueryNameString…

Ok, I remember I encountered this once as well and looked a bit into it.
As
far as I recall,
ObQueryNameString , for object types which do have an QueryName method,
will
lookup
the object header, object type, then the query name procedure. File
objects
do have a special
query name procedure , a internal OS function called IopQueryName().
This
API is called with some
of the parameters passed to ObQueryNameString() , and Length is one of
them.

The funny part is that this function , as one of the first things,
checks
whatever the Length parameter is at
least greater than the size of a UNICODE_STRING, to accomodate the
minimum
size of required for output,
as defined by OBJECT_NAME_INFO. If the size passed is less then this,
then
the function bails with a
STATUS_INFO_LENGTH_MISMATCH, without updating the required length at
all.

In other cases, ObQueryNameString works as expected, and documented. But
not
in this case, and the implementation
flaw is in query name method for files. I wanted to report this, but i
forgot unfortunately.

Regards,
Dan Partelly, Microsoft MVP for Windows DDK

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

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

7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi guys,
well i can confirm what Dan says. The FILE_OBJECTs i encountered this
behaviour with are ntfs file objects. Using ObQueryNameString with 0 length
and with
a registry key object infact worked fine. What it puzzles again is that,
with the code i posted, it works also with NULL as the buffer pointer
(again, not for ntfs file objects).
I tried with NULL coz i expected (from the DDK) the function would take this
path :

  1. query the name itself
  2. check my buffer and length
  3. if both are ok, fill buffer and length
  4. if length is 0, do not fill buffer but update ReturnLength
  5. then, one can recall the function with proper buffer and size

Maybe it was just my misunderstanding, but seems the query on non ntfs
fileobjects works exactly that way. On ntfs file objects, it works as Dan
says.
Tony, i can confirm this behaviour on at least 2ksp2 and xpsp1. Haven’t
tested other service packs and version.

Also Tony , you say

>That it works with a zero length buffer at all actually surprises me,
>and probably is what leads to the confusion here.
That is explictly said in the ddk that it works with a zerolength buffer…
and indeed, works for at least registry-key objects (i tried only that and
proper filesystem objects)

Regards,
Valerio

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Technically speaking, it needs to be at least
sizeof(OBJECT_NAME_INFORMATION), since that is the fixed size portion of
the structure you are passing in to this call.

That it works with a zero length buffer at all actually surprises me,
and probably is what leads to the confusion here. However, note that
in general the interfaces require that the buffer you pass down must be
the size of the fixed portion of the structure.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class in Boston, MA, March
29, 2004!

- -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Partelly
Sent: Wednesday, February 11, 2004 1:09 PM
To: ntfsd redirect
Subject: Re: [ntfsd] Weird behaviour of ObQueryNameString…

Ok, I remember I encountered this once as well and looked a bit into it.
As
far as I recall,
ObQueryNameString , for object types which do have an QueryName method,
will
lookup
the object header, object type, then the query name procedure. File
objects
do have a special
query name procedure , a internal OS function called IopQueryName().
This
API is called with some
of the parameters passed to ObQueryNameString() , and Length is one of
them.

The funny part is that this function , as one of the first things,
checks
whatever the Length parameter is at
least greater than the size of a UNICODE_STRING, to accomodate the
minimum
size of required for output,
as defined by OBJECT_NAME_INFO. If the size passed is less then this,
then
the function bails with a
STATUS_INFO_LENGTH_MISMATCH, without updating the required length at
all.

In other cases, ObQueryNameString works as expected, and documented. But
not
in this case, and the implementation
flaw is in query name method for files. I wanted to report this, but i
forgot unfortunately.

Regards,
Dan Partelly, Microsoft MVP for Windows DDK

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

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

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQCqLLmGxr2U3nc5EEQJdZwCfVy6y63I8LC5JBidwQWLgdP+YbEgAoJKN
ZC/mgt06ZjfZRWrTXlkRLIR8
=0TR3
-----END PGP SIGNATURE-----

8

This operation works differently based on the “class” of object being
used. For “File” class objects in the system a length of zero will not
return the real length they need. This is because “File” class objects
have their own QueryNameProcuedre. As Tony said the code requires that
the buffer be big enough to hold an OBJECT_NAME_INFORMATION structure or
it returns immediately.

I would expect this behavior on all file systems (not just ntfs) but
other object classes in the system might function differently.

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 Valerino
Sent: Wednesday, February 11, 2004 12:06 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Weird behaviour of ObQueryNameString…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi guys,
well i can confirm what Dan says. The FILE_OBJECTs i encountered this
behaviour with are ntfs file objects. Using ObQueryNameString with 0
length
and with
a registry key object infact worked fine. What it puzzles again is that,
with the code i posted, it works also with NULL as the buffer pointer
(again, not for ntfs file objects).
I tried with NULL coz i expected (from the DDK) the function would take
this
path :

  1. query the name itself
  2. check my buffer and length
  3. if both are ok, fill buffer and length
  4. if length is 0, do not fill buffer but update ReturnLength
  5. then, one can recall the function with proper buffer and size

Maybe it was just my misunderstanding, but seems the query on non ntfs
fileobjects works exactly that way. On ntfs file objects, it works as
Dan
says.
Tony, i can confirm this behaviour on at least 2ksp2 and xpsp1. Haven’t
tested other service packs and version.

Also Tony , you say

>That it works with a zero length buffer at all actually surprises me,
>and probably is what leads to the confusion here.
That is explictly said in the ddk that it works with a zerolength
buffer…
and indeed, works for at least registry-key objects (i tried only that
and
proper filesystem objects)

Regards,
Valerio

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Technically speaking, it needs to be at least
sizeof(OBJECT_NAME_INFORMATION), since that is the fixed size portion of
the structure you are passing in to this call.

That it works with a zero length buffer at all actually surprises me,
and probably is what leads to the confusion here. However, note that
in general the interfaces require that the buffer you pass down must be
the size of the fixed portion of the structure.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class in Boston, MA, March
29, 2004!

- -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Partelly
Sent: Wednesday, February 11, 2004 1:09 PM
To: ntfsd redirect
Subject: Re: [ntfsd] Weird behaviour of ObQueryNameString…

Ok, I remember I encountered this once as well and looked a bit into it.
As
far as I recall,
ObQueryNameString , for object types which do have an QueryName method,
will
lookup
the object header, object type, then the query name procedure. File
objects
do have a special
query name procedure , a internal OS function called IopQueryName().
This
API is called with some
of the parameters passed to ObQueryNameString() , and Length is one of
them.

The funny part is that this function , as one of the first things,
checks
whatever the Length parameter is at
least greater than the size of a UNICODE_STRING, to accomodate the
minimum
size of required for output,
as defined by OBJECT_NAME_INFO. If the size passed is less then this,
then
the function bails with a
STATUS_INFO_LENGTH_MISMATCH, without updating the required length at
all.

In other cases, ObQueryNameString works as expected, and documented. But
not
in this case, and the implementation
flaw is in query name method for files. I wanted to report this, but i
forgot unfortunately.

Regards,
Dan Partelly, Microsoft MVP for Windows DDK

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

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

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBQCqLLmGxr2U3nc5EEQJdZwCfVy6y63I8LC5JBidwQWLgdP+YbEgAoJKN
ZC/mgt06ZjfZRWrTXlkRLIR8
=0TR3
-----END PGP SIGNATURE-----

—
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