I got an assertion in a call to FltGetFileNameInformationUnsafe that said
the name was too long (unfortunately I forgot to save the error message).
The length of the name in the file object was 306 characters so the total
length was probably 323 chars. FltGetFileNameInformationUnsafe allocates
it’s own memory for the structure so I cannot see anything I can do to fix
this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify “\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to create
paths (e.g., using relative paths) that cannot be accessed because their
full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that said
the name was too long (unfortunately I forgot to save the error message).
The length of the name in the file object was 306 characters so the total
length was probably 323 chars. FltGetFileNameInformationUnsafe allocates
it’s own memory for the structure so I cannot see anything I can do to fix
this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
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
“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Mark:
>
> In general, Windows chokes on any path > MAX_PATH (260) characters. The
> Windows API has “several functions” where you can specify “\?\C:\path…”
> and get up to 32K characters. It also states that it’s possible to create
> paths (e.g., using relative paths) that cannot be accessed because their
> full path names would be too long.
>
> My experience has been that you’re stuck with the 260 character maximum
> length path.
I don’t understand. I didn’t create this path, windows did.
What am I supposed to do? The reason I call FltGetFileNameInformationUnsafe
is to get the path. If it can’t handle a windows created path without
crashing then I can’t call it. How do you get paths?
If this limitation is present in the mini filter manager, that would be
a bug, however, because filter drivers have to be able to handle things
that might not work in the Win32 layer. For example, a system running
SFU with a number of NFS clients would not be aware of this
implementation decision within Win32. A product that breaks in such an
environment would be unacceptable as a commercial application (at least
as far as I’m concerned).
I have no idea if this IS an issue with the mini-filter, but if so it
needs to be reported and fixed. Filters MUST be able to work with full
sized path names, and names that are presented in other subsystems
besides Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, March 29, 2005 2:14 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify
“\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to
create
paths (e.g., using relative paths) that cannot be accessed because their
full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that
said
the name was too long (unfortunately I forgot to save the error
message).
The length of the name in the file object was 306 characters so the
total
length was probably 323 chars. FltGetFileNameInformationUnsafe
allocates
it’s own memory for the structure so I cannot see anything I can do to
fix
this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
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@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Mark:
Are you sure it’s 306 characters and not 306 bytes? It’s easy to get
chars/bytes mixed up when you’re dealing with Unicode…
I use FltGetFileNameInformation extensively, as well as
FltGetDestinationFileNameInformation, but I’ve not used
FltGetFileNameInformationUnsafe. I’ve never had a problem.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:18 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Mark:
>
> In general, Windows chokes on any path > MAX_PATH (260) characters. The
> Windows API has “several functions” where you can specify “\?\C:\path…”
> and get up to 32K characters. It also states that it’s possible to create
> paths (e.g., using relative paths) that cannot be accessed because their
> full path names would be too long.
>
> My experience has been that you’re stuck with the 260 character maximum
> length path.
I don’t understand. I didn’t create this path, windows did.
What am I supposed to do? The reason I call FltGetFileNameInformationUnsafe
is to get the path. If it can’t handle a windows created path without
crashing then I can’t call it. How do you get paths?
—
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
Tony:
Right. I’ve not seen a problem in my mini-filter – only in the Windows API
stuff I mentioned. I’m not sure where Mark is getting clobbered but I
haven’t used the specific routine he referenced
(FltGetFileNameInformationUnsafe – sounds scary, huh?)
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, March 29, 2005 2:27 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
If this limitation is present in the mini filter manager, that would be
a bug, however, because filter drivers have to be able to handle things
that might not work in the Win32 layer. For example, a system running
SFU with a number of NFS clients would not be aware of this
implementation decision within Win32. A product that breaks in such an
environment would be unacceptable as a commercial application (at least
as far as I’m concerned).
I have no idea if this IS an issue with the mini-filter, but if so it
needs to be reported and fixed. Filters MUST be able to work with full
sized path names, and names that are presented in other subsystems
besides Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, March 29, 2005 2:14 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify
“\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to
create
paths (e.g., using relative paths) that cannot be accessed because their
full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that
said
the name was too long (unfortunately I forgot to save the error
message).
The length of the name in the file object was 306 characters so the
total
length was probably 323 chars. FltGetFileNameInformationUnsafe
allocates
it’s own memory for the structure so I cannot see anything I can do to
fix
this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
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@osr.com
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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
The FltGetFileName* APIs work with file names that are up to the file
system limit. A name of 306 characters should be no problem. I haven’t
seen any similar problems in our internal testing of the filter manager
or of minifilters we’ve written.
There is no ASSERT in filter manager that would check to ensure that a
name is less than MAX_PATH. There are assertions at various places to
check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
being build is consistent - i.e., the total name length >= the volume
name length, the total name length > the stream length, etc.
If you could send me the exact message you are seeing, it would help
figure out what is going on here.
Regards,
Molly Brown
Microsoft Corporation
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 Ken Cross
Sent: Tuesday, March 29, 2005 11:40 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Tony:
Right. I’ve not seen a problem in my mini-filter – only in the Windows
API stuff I mentioned. I’m not sure where Mark is getting clobbered but
I haven’t used the specific routine he referenced
(FltGetFileNameInformationUnsafe – sounds scary, huh?)
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, March 29, 2005 2:27 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
If this limitation is present in the mini filter manager, that would be
a bug, however, because filter drivers have to be able to handle things
that might not work in the Win32 layer. For example, a system running
SFU with a number of NFS clients would not be aware of this
implementation decision within Win32. A product that breaks in such an
environment would be unacceptable as a commercial application (at least
as far as I’m concerned).
I have no idea if this IS an issue with the mini-filter, but if so it
needs to be reported and fixed. Filters MUST be able to work with full
sized path names, and names that are presented in other subsystems
besides Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, March 29, 2005 2:14 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify
“\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to
create paths (e.g., using relative paths) that cannot be accessed
because their full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that
said the name was too long (unfortunately I forgot to save the error
message).
The length of the name in the file object was 306 characters so the
total length was probably 323 chars. FltGetFileNameInformationUnsafe
allocates it’s own memory for the structure so I cannot see anything I
can do to fix this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
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@osr.com
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: unknown lmsubst tag argument:
‘’
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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are right, it was bytes, so the total length would be 340 bytes or 170
chars.
“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Mark:
>
> Are you sure it’s 306 characters and not 306 bytes? It’s easy to get
> chars/bytes mixed up when you’re dealing with Unicode…
>
> I use FltGetFileNameInformation extensively, as well as
> FltGetDestinationFileNameInformation, but I’ve not used
> FltGetFileNameInformationUnsafe. I’ve never had a problem.
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Tuesday, March 29, 2005 2:18 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
>
>
> “Ken Cross” wrote in message news:xxxxx@ntfsd…
>> Mark:
>>
>> In general, Windows chokes on any path > MAX_PATH (260) characters. The
>> Windows API has “several functions” where you can specify
>> “\?\C:\path…”
>> and get up to 32K characters. It also states that it’s possible to
>> create
>> paths (e.g., using relative paths) that cannot be accessed because their
>> full path names would be too long.
>>
>> My experience has been that you’re stuck with the 260 character maximum
>> length path.
>
> I don’t understand. I didn’t create this path, windows did.
>
> What am I supposed to do? The reason I call
> FltGetFileNameInformationUnsafe
>
> is to get the path. If it can’t handle a windows created path without
> crashing then I can’t call it. How do you get paths?
>
>
>
> —
> 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
>
>
If / when I see it again I will post it. I assumed it was my fault by not
allocating enough mem until I looked up the docs and saw that I wasn’t the
one allocating the memory.
The error mentioned the path length and had a >= in it. That is all I can
remember.
“Molly Brown” wrote in message
news:xxxxx@ntfsd…
The FltGetFileName* APIs work with file names that are up to the file
system limit. A name of 306 characters should be no problem. I haven’t
seen any similar problems in our internal testing of the filter manager
or of minifilters we’ve written.
There is no ASSERT in filter manager that would check to ensure that a
name is less than MAX_PATH. There are assertions at various places to
check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
being build is consistent - i.e., the total name length >= the volume
name length, the total name length > the stream length, etc.
If you could send me the exact message you are seeing, it would help
figure out what is going on here.
Regards,
Molly Brown
Microsoft Corporation
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 Ken Cross
Sent: Tuesday, March 29, 2005 11:40 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Tony:
Right. I’ve not seen a problem in my mini-filter – only in the Windows
API stuff I mentioned. I’m not sure where Mark is getting clobbered but
I haven’t used the specific routine he referenced
(FltGetFileNameInformationUnsafe – sounds scary, huh?)
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, March 29, 2005 2:27 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
If this limitation is present in the mini filter manager, that would be
a bug, however, because filter drivers have to be able to handle things
that might not work in the Win32 layer. For example, a system running
SFU with a number of NFS clients would not be aware of this
implementation decision within Win32. A product that breaks in such an
environment would be unacceptable as a commercial application (at least
as far as I’m concerned).
I have no idea if this IS an issue with the mini-filter, but if so it
needs to be reported and fixed. Filters MUST be able to work with full
sized path names, and names that are presented in other subsystems
besides Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, March 29, 2005 2:14 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify
“\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to
create paths (e.g., using relative paths) that cannot be accessed
because their full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that
said the name was too long (unfortunately I forgot to save the error
message).
The length of the name in the file object was 306 characters so the
total length was probably 323 chars. FltGetFileNameInformationUnsafe
allocates it’s own memory for the structure so I cannot see anything I
can do to fix this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
—
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@osr.com
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: unknown lmsubst tag argument:
‘’
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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I got the assertion error again. It looked like this:
*** Assertion failed: NewSize > NameCtrl->BufferSize
*** Source File: d:\xpsprtm\base\fs\filtermgr\filter\namesup.c, line 516
The FileObject->FileName was: “\System Volume
Information_restore{387E7129-1274-4AFC-B9C8-5D596D9B45AB}\RP26\snapshot_REGISTRY_USER_NTUSER_S-1-5-21-1645522239-823518204-682003330-500”,
which is 153 chars.
My call was:
PFLT_FILE_NAME_INFORMATION fileNameInfo;
status = FltGetFileNameInformationUnsafe( FileObject, Instance,
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &fileNameInfo );
The stack was:
f6602020 80abbf3e e1096958 00000360 81d414e8 nt!DbgBreakPoint
f6602310 80abbf80 bbddbc12 bbddbbe2 00000204 nt!RtlAssert2+0x104
f660232c bbddbd23 bbddbc12 bbddbbe2 00000204 nt!RtlAssert+0x18
f6602350 bbddd464 81d414e8 00000360 00000000
fltmgr!FltpReallocNameControl+0x5f
f6602378 bbde2690 81cf0a18 80abbf68 81d39f88 fltmgr!FltpGetFileName+0x23e
f6602390 bbdd6d82 81d39f88 80abbf68 81d39f88
fltmgr!FltpGetOpenedFileName+0x92
f66023ac bbde2c4e 81d39f88 80abbf68 81d39f88
fltmgr!FltpCallOpenedFileNameHandler+0xdc
f66023c8 bbde3dbb 81d39f88 00000000 81d39f88
fltmgr!FltpGetNormalizedFileNameWorker+0x182
f66023e4 bbdd9594 81d39f88 80abbf68 81cf07d0
fltmgr!FltpGetNormalizedFileName+0x79
f66023fc bbdd9b47 80aec000 00000000 81d39f88
fltmgr!FltpCreateFileNameInformation+0x15e
f6602414 bbda1344 81d39f88 81c0ee58 00000000
fltmgr!CreateTemporaryFileNameInformation+0x8b
f6602444 bbddb6fb 81d39f88 0000001a 81ca7760
fltmgr!FltpGetFileNameInformation+0x138
f6602468 f686490c 81c0ee58 81bf98a0 00000101
fltmgr!FltGetFileNameInformationUnsafe+0x15d
f66024a4 f6863ef0 e1a6a914 81cf04f8 81c0ee58 DeqoCPS!CpsPostOpenRec+0x9c
f66024dc f6863855 81cf04f8 81c0ee58 81bf98a0
DeqoCPS!CpsGetStreamContext+0x1b0
f660253c bbdf0033 81cd1464 f6602588 f66025b8 DeqoCPS!CpsPreWrite+0x95
f6602568 bbd896e6 00000001 00000004 f66025b8 fltmgr!FltvPreOperation+0x3f
f66025d4 bbd94e65 f6602620 00000000 83362fdc
fltmgr!FltpPerformPreCallbacks+0x6a0
f66025ec bbd97dee f6602620 00000000 81cf0960
fltmgr!FltpPassThroughInternal+0xdb
f6602608 bbd99255 83362f00 81cf0960 83362e28 fltmgr!FltpPassThrough+0x584
DeqoCPS is my mini-filter.
“Molly Brown” wrote in message
news:xxxxx@ntfsd…
The FltGetFileName* APIs work with file names that are up to the file
system limit. A name of 306 characters should be no problem. I haven’t
seen any similar problems in our internal testing of the filter manager
or of minifilters we’ve written.
There is no ASSERT in filter manager that would check to ensure that a
name is less than MAX_PATH. There are assertions at various places to
check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
being build is consistent - i.e., the total name length >= the volume
name length, the total name length > the stream length, etc.
If you could send me the exact message you are seeing, it would help
figure out what is going on here.
Regards,
Molly Brown
Microsoft Corporation
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 Ken Cross
Sent: Tuesday, March 29, 2005 11:40 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Tony:
Right. I’ve not seen a problem in my mini-filter – only in the Windows
API stuff I mentioned. I’m not sure where Mark is getting clobbered but
I haven’t used the specific routine he referenced
(FltGetFileNameInformationUnsafe – sounds scary, huh?)
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, March 29, 2005 2:27 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
If this limitation is present in the mini filter manager, that would be
a bug, however, because filter drivers have to be able to handle things
that might not work in the Win32 layer. For example, a system running
SFU with a number of NFS clients would not be aware of this
implementation decision within Win32. A product that breaks in such an
environment would be unacceptable as a commercial application (at least
as far as I’m concerned).
I have no idea if this IS an issue with the mini-filter, but if so it
needs to be reported and fixed. Filters MUST be able to work with full
sized path names, and names that are presented in other subsystems
besides Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, March 29, 2005 2:14 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify
“\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to
create paths (e.g., using relative paths) that cannot be accessed
because their full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that
said the name was too long (unfortunately I forgot to save the error
message).
The length of the name in the file object was 306 characters so the
total length was probably 323 chars. FltGetFileNameInformationUnsafe
allocates it’s own memory for the structure so I cannot see anything I
can do to fix this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
—
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@osr.com
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: unknown lmsubst tag argument:
‘’
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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Does your filter do any processing of IRP_MJ_QUERY_INFORMATION? This
assertion basically says “ensure the new allocation is bigger than the
size of the current buffer” and the fact it fails is odd. One possible
cause of this is if you are trying to process a name request coming from
the underlying file system and not handling it properly.
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 Mark Hahn
Sent: Tuesday, March 29, 2005 8:16 PM
To: ntfsd redirect
Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
I got the assertion error again. It looked like this:
*** Assertion failed: NewSize > NameCtrl->BufferSize
*** Source File: d:\xpsprtm\base\fs\filtermgr\filter\namesup.c, line 516
The FileObject->FileName was: “\System Volume
Information_restore{387E7129-1274-4AFC-B9C8-5D596D9B45AB}\RP26\snapshot
_REGISTRY_USER_NTUSER_S-1-5-21-1645522239-823518204-682003330-500”,
which is 153 chars.
My call was:
PFLT_FILE_NAME_INFORMATION fileNameInfo;
status = FltGetFileNameInformationUnsafe( FileObject, Instance,
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &fileNameInfo
);
The stack was:
f6602020 80abbf3e e1096958 00000360 81d414e8 nt!DbgBreakPoint
f6602310 80abbf80 bbddbc12 bbddbbe2 00000204 nt!RtlAssert2+0x104
f660232c bbddbd23 bbddbc12 bbddbbe2 00000204 nt!RtlAssert+0x18
f6602350 bbddd464 81d414e8 00000360 00000000
fltmgr!FltpReallocNameControl+0x5f
f6602378 bbde2690 81cf0a18 80abbf68 81d39f88
fltmgr!FltpGetFileName+0x23e
f6602390 bbdd6d82 81d39f88 80abbf68 81d39f88
fltmgr!FltpGetOpenedFileName+0x92
f66023ac bbde2c4e 81d39f88 80abbf68 81d39f88
fltmgr!FltpCallOpenedFileNameHandler+0xdc
f66023c8 bbde3dbb 81d39f88 00000000 81d39f88
fltmgr!FltpGetNormalizedFileNameWorker+0x182
f66023e4 bbdd9594 81d39f88 80abbf68 81cf07d0
fltmgr!FltpGetNormalizedFileName+0x79
f66023fc bbdd9b47 80aec000 00000000 81d39f88
fltmgr!FltpCreateFileNameInformation+0x15e
f6602414 bbda1344 81d39f88 81c0ee58 00000000
fltmgr!CreateTemporaryFileNameInformation+0x8b
f6602444 bbddb6fb 81d39f88 0000001a 81ca7760
fltmgr!FltpGetFileNameInformation+0x138
f6602468 f686490c 81c0ee58 81bf98a0 00000101
fltmgr!FltGetFileNameInformationUnsafe+0x15d
f66024a4 f6863ef0 e1a6a914 81cf04f8 81c0ee58 DeqoCPS!CpsPostOpenRec+0x9c
f66024dc f6863855 81cf04f8 81c0ee58 81bf98a0
DeqoCPS!CpsGetStreamContext+0x1b0
f660253c bbdf0033 81cd1464 f6602588 f66025b8 DeqoCPS!CpsPreWrite+0x95
f6602568 bbd896e6 00000001 00000004 f66025b8
fltmgr!FltvPreOperation+0x3f
f66025d4 bbd94e65 f6602620 00000000 83362fdc
fltmgr!FltpPerformPreCallbacks+0x6a0
f66025ec bbd97dee f6602620 00000000 81cf0960
fltmgr!FltpPassThroughInternal+0xdb
f6602608 bbd99255 83362f00 81cf0960 83362e28
fltmgr!FltpPassThrough+0x584
DeqoCPS is my mini-filter.
“Molly Brown” wrote in message
news:xxxxx@ntfsd…
The FltGetFileName* APIs work with file names that are up to the file
system limit. A name of 306 characters should be no problem. I haven’t
seen any similar problems in our internal testing of the filter manager
or of minifilters we’ve written.
There is no ASSERT in filter manager that would check to ensure that a
name is less than MAX_PATH. There are assertions at various places to
check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
being build is consistent - i.e., the total name length >= the volume
name length, the total name length > the stream length, etc.
If you could send me the exact message you are seeing, it would help
figure out what is going on here.
Regards,
Molly Brown
Microsoft Corporation
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 Ken Cross
Sent: Tuesday, March 29, 2005 11:40 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Tony:
Right. I’ve not seen a problem in my mini-filter – only in the Windows
API stuff I mentioned. I’m not sure where Mark is getting clobbered but
I haven’t used the specific routine he referenced
(FltGetFileNameInformationUnsafe – sounds scary, huh?)
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, March 29, 2005 2:27 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
If this limitation is present in the mini filter manager, that would be
a bug, however, because filter drivers have to be able to handle things
that might not work in the Win32 layer. For example, a system running
SFU with a number of NFS clients would not be aware of this
implementation decision within Win32. A product that breaks in such an
environment would be unacceptable as a commercial application (at least
as far as I’m concerned).
I have no idea if this IS an issue with the mini-filter, but if so it
needs to be reported and fixed. Filters MUST be able to work with full
sized path names, and names that are presented in other subsystems
besides Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, March 29, 2005 2:14 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify
“\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to
create paths (e.g., using relative paths) that cannot be accessed
because their full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that
said the name was too long (unfortunately I forgot to save the error
message).
The length of the name in the file object was 306 characters so the
total length was probably 323 chars. FltGetFileNameInformationUnsafe
allocates it’s own memory for the structure so I cannot see anything I
can do to fix this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
—
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@osr.com
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: unknown lmsubst tag argument:
‘’
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@windows.microsoft.com
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@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I think Tony is on to something here.
The filter manager has just issued a IRP_MJ_QUERY_INFORMATION query with
the FileNameInformation information class. STATUS_BUFFER_OVERFLOW was
returned, indicating that the buffer was not large enough. The file
system should have returned the length needed to store the name in
FileNameLength field of the FILE_NAME_INFORMATION structure passed into
the IRP_MJ_QUERY_INFORMATION.
Filter manager builds up the new name buffer size based on the length
based on the FILE_NAME_INFORMATION.FileNameLength plus the device name
size and some padding for short name expansion. Since
STATUS_BUFFER_OVERFLOW indicated that the original buffer size was too
small, the new buffer size calculated from the
FILE_NAME_INFORMATION.FileNameLength should always be larger than the
original buffer size.
Regards,
Molly Brown
Microsoft Corporation
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 Tony Mason
Sent: Tuesday, March 29, 2005 5:35 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Does your filter do any processing of IRP_MJ_QUERY_INFORMATION? This
assertion basically says “ensure the new allocation is bigger than the
size of the current buffer” and the fact it fails is odd. One possible
cause of this is if you are trying to process a name request coming from
the underlying file system and not handling it properly.
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 Mark Hahn
Sent: Tuesday, March 29, 2005 8:16 PM
To: ntfsd redirect
Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
I got the assertion error again. It looked like this:
*** Assertion failed: NewSize > NameCtrl->BufferSize
*** Source File: d:\xpsprtm\base\fs\filtermgr\filter\namesup.c, line 516
The FileObject->FileName was: “\System Volume
Information_restore{387E7129-1274-4AFC-B9C8-5D596D9B45AB}\RP26\snapshot
_REGISTRY_USER_NTUSER_S-1-5-21-1645522239-823518204-682003330-500”,
which is 153 chars.
My call was:
PFLT_FILE_NAME_INFORMATION fileNameInfo; status =
FltGetFileNameInformationUnsafe( FileObject, Instance,
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &fileNameInfo
);
The stack was:
f6602020 80abbf3e e1096958 00000360 81d414e8 nt!DbgBreakPoint f6602310
80abbf80 bbddbc12 bbddbbe2 00000204 nt!RtlAssert2+0x104 f660232c
bbddbd23 bbddbc12 bbddbbe2 00000204 nt!RtlAssert+0x18 f6602350 bbddd464
81d414e8 00000360 00000000 fltmgr!FltpReallocNameControl+0x5f
f6602378 bbde2690 81cf0a18 80abbf68 81d39f88
fltmgr!FltpGetFileName+0x23e f6602390 bbdd6d82 81d39f88 80abbf68
81d39f88
fltmgr!FltpGetOpenedFileName+0x92
f66023ac bbde2c4e 81d39f88 80abbf68 81d39f88
fltmgr!FltpCallOpenedFileNameHandler+0xdc
f66023c8 bbde3dbb 81d39f88 00000000 81d39f88
fltmgr!FltpGetNormalizedFileNameWorker+0x182
f66023e4 bbdd9594 81d39f88 80abbf68 81cf07d0
fltmgr!FltpGetNormalizedFileName+0x79
f66023fc bbdd9b47 80aec000 00000000 81d39f88
fltmgr!FltpCreateFileNameInformation+0x15e
f6602414 bbda1344 81d39f88 81c0ee58 00000000
fltmgr!CreateTemporaryFileNameInformation+0x8b
f6602444 bbddb6fb 81d39f88 0000001a 81ca7760
fltmgr!FltpGetFileNameInformation+0x138
f6602468 f686490c 81c0ee58 81bf98a0 00000101
fltmgr!FltGetFileNameInformationUnsafe+0x15d
f66024a4 f6863ef0 e1a6a914 81cf04f8 81c0ee58 DeqoCPS!CpsPostOpenRec+0x9c
f66024dc f6863855 81cf04f8 81c0ee58 81bf98a0
DeqoCPS!CpsGetStreamContext+0x1b0 f660253c bbdf0033 81cd1464 f6602588
f66025b8 DeqoCPS!CpsPreWrite+0x95
f6602568 bbd896e6 00000001 00000004 f66025b8
fltmgr!FltvPreOperation+0x3f
f66025d4 bbd94e65 f6602620 00000000 83362fdc
fltmgr!FltpPerformPreCallbacks+0x6a0
f66025ec bbd97dee f6602620 00000000 81cf0960
fltmgr!FltpPassThroughInternal+0xdb
f6602608 bbd99255 83362f00 81cf0960 83362e28
fltmgr!FltpPassThrough+0x584
DeqoCPS is my mini-filter.
“Molly Brown” wrote in message
news:xxxxx@ntfsd…
The FltGetFileName* APIs work with file names that are up to the file
system limit. A name of 306 characters should be no problem. I haven’t
seen any similar problems in our internal testing of the filter manager
or of minifilters we’ve written.
There is no ASSERT in filter manager that would check to ensure that a
name is less than MAX_PATH. There are assertions at various places to
check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
being build is consistent - i.e., the total name length >= the volume
name length, the total name length > the stream length, etc.
If you could send me the exact message you are seeing, it would help
figure out what is going on here.
Regards,
Molly Brown
Microsoft Corporation
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 Ken Cross
Sent: Tuesday, March 29, 2005 11:40 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Tony:
Right. I’ve not seen a problem in my mini-filter – only in the Windows
API stuff I mentioned. I’m not sure where Mark is getting clobbered but
I haven’t used the specific routine he referenced
(FltGetFileNameInformationUnsafe – sounds scary, huh?)
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, March 29, 2005 2:27 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
If this limitation is present in the mini filter manager, that would be
a bug, however, because filter drivers have to be able to handle things
that might not work in the Win32 layer. For example, a system running
SFU with a number of NFS clients would not be aware of this
implementation decision within Win32. A product that breaks in such an
environment would be unacceptable as a commercial application (at least
as far as I’m concerned).
I have no idea if this IS an issue with the mini-filter, but if so it
needs to be reported and fixed. Filters MUST be able to work with full
sized path names, and names that are presented in other subsystems
besides Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, March 29, 2005 2:14 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify
“\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to
create paths (e.g., using relative paths) that cannot be accessed
because their full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that
said the name was too long (unfortunately I forgot to save the error
message).
The length of the name in the file object was 306 characters so the
total length was probably 323 chars. FltGetFileNameInformationUnsafe
allocates it’s own memory for the structure so I cannot see anything I
can do to fix this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
—
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@osr.com 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: unknown lmsubst tag argument:
‘’
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@windows.microsoft.com
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@osr.com 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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
The only processing of IRP_MJ_QUERY_INFORMATION is this call to
FltGetFileNameInformationUnsafe. I don’t see what I am doing wrong. What
should I try next? Could this be a re-entrancy problem? I’ll try
protecting the call with a spin lock.
“Molly Brown” wrote in message
news:xxxxx@ntfsd…
I think Tony is on to something here.
The filter manager has just issued a IRP_MJ_QUERY_INFORMATION query with
the FileNameInformation information class. STATUS_BUFFER_OVERFLOW was
returned, indicating that the buffer was not large enough. The file
system should have returned the length needed to store the name in
FileNameLength field of the FILE_NAME_INFORMATION structure passed into
the IRP_MJ_QUERY_INFORMATION.
Filter manager builds up the new name buffer size based on the length
based on the FILE_NAME_INFORMATION.FileNameLength plus the device name
size and some padding for short name expansion. Since
STATUS_BUFFER_OVERFLOW indicated that the original buffer size was too
small, the new buffer size calculated from the
FILE_NAME_INFORMATION.FileNameLength should always be larger than the
original buffer size.
Regards,
Molly Brown
Microsoft Corporation
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 Tony Mason
Sent: Tuesday, March 29, 2005 5:35 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Does your filter do any processing of IRP_MJ_QUERY_INFORMATION? This
assertion basically says “ensure the new allocation is bigger than the
size of the current buffer” and the fact it fails is odd. One possible
cause of this is if you are trying to process a name request coming from
the underlying file system and not handling it properly.
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 Mark Hahn
Sent: Tuesday, March 29, 2005 8:16 PM
To: ntfsd redirect
Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
I got the assertion error again. It looked like this:
Assertion failed: NewSize > NameCtrl->BufferSize
Source File: d:\xpsprtm\base\fs\filtermgr\filter\namesup.c, line 516
The FileObject->FileName was: “\System Volume
Information_restore{387E7129-1274-4AFC-B9C8-5D596D9B45AB}\RP26\snapshot
_REGISTRY_USER_NTUSER_S-1-5-21-1645522239-823518204-682003330-500”,
which is 153 chars.
My call was:
PFLT_FILE_NAME_INFORMATION fileNameInfo; status =
FltGetFileNameInformationUnsafe( FileObject, Instance,
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &fileNameInfo
);
The stack was:
f6602020 80abbf3e e1096958 00000360 81d414e8 nt!DbgBreakPoint f6602310
80abbf80 bbddbc12 bbddbbe2 00000204 nt!RtlAssert2+0x104 f660232c
bbddbd23 bbddbc12 bbddbbe2 00000204 nt!RtlAssert+0x18 f6602350 bbddd464
81d414e8 00000360 00000000 fltmgr!FltpReallocNameControl+0x5f
f6602378 bbde2690 81cf0a18 80abbf68 81d39f88
fltmgr!FltpGetFileName+0x23e f6602390 bbdd6d82 81d39f88 80abbf68
81d39f88
fltmgr!FltpGetOpenedFileName+0x92
f66023ac bbde2c4e 81d39f88 80abbf68 81d39f88
fltmgr!FltpCallOpenedFileNameHandler+0xdc
f66023c8 bbde3dbb 81d39f88 00000000 81d39f88
fltmgr!FltpGetNormalizedFileNameWorker+0x182
f66023e4 bbdd9594 81d39f88 80abbf68 81cf07d0
fltmgr!FltpGetNormalizedFileName+0x79
f66023fc bbdd9b47 80aec000 00000000 81d39f88
fltmgr!FltpCreateFileNameInformation+0x15e
f6602414 bbda1344 81d39f88 81c0ee58 00000000
fltmgr!CreateTemporaryFileNameInformation+0x8b
f6602444 bbddb6fb 81d39f88 0000001a 81ca7760
fltmgr!FltpGetFileNameInformation+0x138
f6602468 f686490c 81c0ee58 81bf98a0 00000101
fltmgr!FltGetFileNameInformationUnsafe+0x15d
f66024a4 f6863ef0 e1a6a914 81cf04f8 81c0ee58 DeqoCPS!CpsPostOpenRec+0x9c
f66024dc f6863855 81cf04f8 81c0ee58 81bf98a0
DeqoCPS!CpsGetStreamContext+0x1b0 f660253c bbdf0033 81cd1464 f6602588
f66025b8 DeqoCPS!CpsPreWrite+0x95
f6602568 bbd896e6 00000001 00000004 f66025b8
fltmgr!FltvPreOperation+0x3f
f66025d4 bbd94e65 f6602620 00000000 83362fdc
fltmgr!FltpPerformPreCallbacks+0x6a0
f66025ec bbd97dee f6602620 00000000 81cf0960
fltmgr!FltpPassThroughInternal+0xdb
f6602608 bbd99255 83362f00 81cf0960 83362e28
fltmgr!FltpPassThrough+0x584
DeqoCPS is my mini-filter.
“Molly Brown” wrote in message
news:xxxxx@ntfsd…
The FltGetFileName* APIs work with file names that are up to the file
system limit. A name of 306 characters should be no problem. I haven’t
seen any similar problems in our internal testing of the filter manager
or of minifilters we’ve written.
There is no ASSERT in filter manager that would check to ensure that a
name is less than MAX_PATH. There are assertions at various places to
check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
being build is consistent - i.e., the total name length >= the volume
name length, the total name length > the stream length, etc.
If you could send me the exact message you are seeing, it would help
figure out what is going on here.
Regards,
Molly Brown
Microsoft Corporation
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 Ken Cross
Sent: Tuesday, March 29, 2005 11:40 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Tony:
Right. I’ve not seen a problem in my mini-filter – only in the Windows
API stuff I mentioned. I’m not sure where Mark is getting clobbered but
I haven’t used the specific routine he referenced
(FltGetFileNameInformationUnsafe – sounds scary, huh?)
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, March 29, 2005 2:27 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
If this limitation is present in the mini filter manager, that would be
a bug, however, because filter drivers have to be able to handle things
that might not work in the Win32 layer. For example, a system running
SFU with a number of NFS clients would not be aware of this
implementation decision within Win32. A product that breaks in such an
environment would be unacceptable as a commercial application (at least
as far as I’m concerned).
I have no idea if this IS an issue with the mini-filter, but if so it
needs to be reported and fixed. Filters MUST be able to work with full
sized path names, and names that are presented in other subsystems
besides Win32.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, March 29, 2005 2:14 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
Mark:
In general, Windows chokes on any path > MAX_PATH (260) characters. The
Windows API has “several functions” where you can specify
“\?\C:\path…”
and get up to 32K characters. It also states that it’s possible to
create paths (e.g., using relative paths) that cannot be accessed
because their full path names would be too long.
My experience has been that you’re stuck with the 260 character maximum
length path.
HTH,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Tuesday, March 29, 2005 2:00 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
I got an assertion in a call to FltGetFileNameInformationUnsafe that
said the name was too long (unfortunately I forgot to save the error
message).
The length of the name in the file object was 306 characters so the
total length was probably 323 chars. FltGetFileNameInformationUnsafe
allocates it’s own memory for the structure so I cannot see anything I
can do to fix this.
Has anyone else had this problem? Does this mean I can’t use
FltGetFileNameInformationUnsafe?
—
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@osr.com 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: unknown lmsubst tag argument:
‘’
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@windows.microsoft.com
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@osr.com 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: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
As I suspected, surrounding the call with a spin lock caused it to bugchk.
“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> The only processing of IRP_MJ_QUERY_INFORMATION is this call to
> FltGetFileNameInformationUnsafe. I don’t see what I am doing wrong. What
> should I try next? Could this be a re-entrancy problem? I’ll try
> protecting the call with a spin lock.
>
> “Molly Brown” wrote in message
> news:xxxxx@ntfsd…
> I think Tony is on to something here.
>
> The filter manager has just issued a IRP_MJ_QUERY_INFORMATION query with
> the FileNameInformation information class. STATUS_BUFFER_OVERFLOW was
> returned, indicating that the buffer was not large enough. The file
> system should have returned the length needed to store the name in
> FileNameLength field of the FILE_NAME_INFORMATION structure passed into
> the IRP_MJ_QUERY_INFORMATION.
>
> Filter manager builds up the new name buffer size based on the length
> based on the FILE_NAME_INFORMATION.FileNameLength plus the device name
> size and some padding for short name expansion. Since
> STATUS_BUFFER_OVERFLOW indicated that the original buffer size was too
> small, the new buffer size calculated from the
> FILE_NAME_INFORMATION.FileNameLength should always be larger than the
> original buffer size.
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> 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 Tony Mason
> Sent: Tuesday, March 29, 2005 5:35 PM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Does your filter do any processing of IRP_MJ_QUERY_INFORMATION? This
> assertion basically says “ensure the new allocation is bigger than the
> size of the current buffer” and the fact it fails is odd. One possible
> cause of this is if you are trying to process a name request coming from
> the underlying file system and not handling it properly.
>
> 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 Mark Hahn
> Sent: Tuesday, March 29, 2005 8:16 PM
> To: ntfsd redirect
> Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> I got the assertion error again. It looked like this:
>
> Assertion failed: NewSize > NameCtrl->BufferSize
> Source File: d:\xpsprtm\base\fs\filtermgr\filter\namesup.c, line 516
>
> The FileObject->FileName was: “\System Volume
> Information_restore{387E7129-1274-4AFC-B9C8-5D596D9B45AB}\RP26\snapshot
> _REGISTRY_USER_NTUSER_S-1-5-21-1645522239-823518204-682003330-500”,
> which is 153 chars.
>
> My call was:
>
> PFLT_FILE_NAME_INFORMATION fileNameInfo; status =
> FltGetFileNameInformationUnsafe( FileObject, Instance,
> FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &fileNameInfo
> );
>
> The stack was:
>
> f6602020 80abbf3e e1096958 00000360 81d414e8 nt!DbgBreakPoint f6602310
> 80abbf80 bbddbc12 bbddbbe2 00000204 nt!RtlAssert2+0x104 f660232c
> bbddbd23 bbddbc12 bbddbbe2 00000204 nt!RtlAssert+0x18 f6602350 bbddd464
> 81d414e8 00000360 00000000 fltmgr!FltpReallocNameControl+0x5f
> f6602378 bbde2690 81cf0a18 80abbf68 81d39f88
> fltmgr!FltpGetFileName+0x23e f6602390 bbdd6d82 81d39f88 80abbf68
> 81d39f88
> fltmgr!FltpGetOpenedFileName+0x92
> f66023ac bbde2c4e 81d39f88 80abbf68 81d39f88
> fltmgr!FltpCallOpenedFileNameHandler+0xdc
> f66023c8 bbde3dbb 81d39f88 00000000 81d39f88
> fltmgr!FltpGetNormalizedFileNameWorker+0x182
> f66023e4 bbdd9594 81d39f88 80abbf68 81cf07d0
> fltmgr!FltpGetNormalizedFileName+0x79
> f66023fc bbdd9b47 80aec000 00000000 81d39f88
> fltmgr!FltpCreateFileNameInformation+0x15e
> f6602414 bbda1344 81d39f88 81c0ee58 00000000
> fltmgr!CreateTemporaryFileNameInformation+0x8b
> f6602444 bbddb6fb 81d39f88 0000001a 81ca7760
> fltmgr!FltpGetFileNameInformation+0x138
> f6602468 f686490c 81c0ee58 81bf98a0 00000101
> fltmgr!FltGetFileNameInformationUnsafe+0x15d
> f66024a4 f6863ef0 e1a6a914 81cf04f8 81c0ee58 DeqoCPS!CpsPostOpenRec+0x9c
> f66024dc f6863855 81cf04f8 81c0ee58 81bf98a0
> DeqoCPS!CpsGetStreamContext+0x1b0 f660253c bbdf0033 81cd1464 f6602588
> f66025b8 DeqoCPS!CpsPreWrite+0x95
> f6602568 bbd896e6 00000001 00000004 f66025b8
> fltmgr!FltvPreOperation+0x3f
> f66025d4 bbd94e65 f6602620 00000000 83362fdc
> fltmgr!FltpPerformPreCallbacks+0x6a0
> f66025ec bbd97dee f6602620 00000000 81cf0960
> fltmgr!FltpPassThroughInternal+0xdb
> f6602608 bbd99255 83362f00 81cf0960 83362e28
> fltmgr!FltpPassThrough+0x584
>
> DeqoCPS is my mini-filter.
>
> “Molly Brown” wrote in message
> news:xxxxx@ntfsd…
> The FltGetFileName* APIs work with file names that are up to the file
> system limit. A name of 306 characters should be no problem. I haven’t
> seen any similar problems in our internal testing of the filter manager
> or of minifilters we’ve written.
>
> There is no ASSERT in filter manager that would check to ensure that a
> name is less than MAX_PATH. There are assertions at various places to
> check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
> being build is consistent - i.e., the total name length >= the volume
> name length, the total name length > the stream length, etc.
>
> If you could send me the exact message you are seeing, it would help
> figure out what is going on here.
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> 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 Ken Cross
> Sent: Tuesday, March 29, 2005 11:40 AM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Tony:
>
> Right. I’ve not seen a problem in my mini-filter – only in the Windows
> API stuff I mentioned. I’m not sure where Mark is getting clobbered but
> I haven’t used the specific routine he referenced
> (FltGetFileNameInformationUnsafe – sounds scary, huh?)
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
> Sent: Tuesday, March 29, 2005 2:27 PM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> If this limitation is present in the mini filter manager, that would be
> a bug, however, because filter drivers have to be able to handle things
> that might not work in the Win32 layer. For example, a system running
> SFU with a number of NFS clients would not be aware of this
> implementation decision within Win32. A product that breaks in such an
> environment would be unacceptable as a commercial application (at least
> as far as I’m concerned).
>
> I have no idea if this IS an issue with the mini-filter, but if so it
> needs to be reported and fixed. Filters MUST be able to work with full
> sized path names, and names that are presented in other subsystems
> besides Win32.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems Class April
> 4, 2005 in Boston!
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
> Sent: Tuesday, March 29, 2005 2:14 PM
> To: ntfsd redirect
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Mark:
>
> In general, Windows chokes on any path > MAX_PATH (260) characters. The
> Windows API has “several functions” where you can specify
> “\?\C:\path…”
> and get up to 32K characters. It also states that it’s possible to
> create paths (e.g., using relative paths) that cannot be accessed
> because their full path names would be too long.
>
> My experience has been that you’re stuck with the 260 character maximum
> length path.
>
> HTH,
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Tuesday, March 29, 2005 2:00 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> I got an assertion in a call to FltGetFileNameInformationUnsafe that
> said the name was too long (unfortunately I forgot to save the error
> message).
> The length of the name in the file object was 306 characters so the
> total length was probably 323 chars. FltGetFileNameInformationUnsafe
> allocates it’s own memory for the structure so I cannot see anything I
> can do to fix this.
>
> Has anyone else had this problem? Does this mean I can’t use
> FltGetFileNameInformationUnsafe?
>
>
>
> —
> 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@osr.com 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: unknown lmsubst tag argument:
> ‘’
> 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@windows.microsoft.com
> 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@osr.com 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: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
Mark,
I am not quite sure what adding a spinlock was supposed to accomplish.
This is not a synchronization issue.
I have a couple of questions:
The query information operation will go below you so your filter will
not be involved with this. We need to know why we are getting a bad
length returned.
As a side question why are you calling the UNSAFE version of the naming
API. When processing an operation you should ONLY call the regular
version. The only reason for having the UNSAFE version is so filters
could query for names out-of-band of an operation, for example in a
worker thread unrelated to an operation
The reason to call the normal one from inside of an operation (and pass
in the callback data) is because the API knows when it is safe to query
the file system for the name. If it is not safe an error will be
returned. If you call the unsafe routine because of this limitation is
wrong because you will cause the system to deadlock periodically.
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 Mark Hahn
Sent: Tuesday, March 29, 2005 8:33 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
As I suspected, surrounding the call with a spin lock caused it to
bugchk.
“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> The only processing of IRP_MJ_QUERY_INFORMATION is this call to
> FltGetFileNameInformationUnsafe. I don’t see what I am doing wrong.
What
> should I try next? Could this be a re-entrancy problem? I’ll try
> protecting the call with a spin lock.
>
> “Molly Brown” wrote in message
> news:xxxxx@ntfsd…
> I think Tony is on to something here.
>
> The filter manager has just issued a IRP_MJ_QUERY_INFORMATION query
with
> the FileNameInformation information class. STATUS_BUFFER_OVERFLOW was
> returned, indicating that the buffer was not large enough. The file
> system should have returned the length needed to store the name in
> FileNameLength field of the FILE_NAME_INFORMATION structure passed
into
> the IRP_MJ_QUERY_INFORMATION.
>
> Filter manager builds up the new name buffer size based on the length
> based on the FILE_NAME_INFORMATION.FileNameLength plus the device name
> size and some padding for short name expansion. Since
> STATUS_BUFFER_OVERFLOW indicated that the original buffer size was too
> small, the new buffer size calculated from the
> FILE_NAME_INFORMATION.FileNameLength should always be larger than the
> original buffer size.
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> 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 Tony Mason
> Sent: Tuesday, March 29, 2005 5:35 PM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Does your filter do any processing of IRP_MJ_QUERY_INFORMATION? This
> assertion basically says “ensure the new allocation is bigger than the
> size of the current buffer” and the fact it fails is odd. One
possible
> cause of this is if you are trying to process a name request coming
from
> the underlying file system and not handling it properly.
>
> 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 Mark Hahn
> Sent: Tuesday, March 29, 2005 8:16 PM
> To: ntfsd redirect
> Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> I got the assertion error again. It looked like this:
>
> Assertion failed: NewSize > NameCtrl->BufferSize
> Source File: d:\xpsprtm\base\fs\filtermgr\filter\namesup.c, line
516
>
> The FileObject->FileName was: “\System Volume
>
Information_restore{387E7129-1274-4AFC-B9C8-5D596D9B45AB}\RP26\snapshot
> _REGISTRY_USER_NTUSER_S-1-5-21-1645522239-823518204-682003330-500”,
> which is 153 chars.
>
> My call was:
>
> PFLT_FILE_NAME_INFORMATION fileNameInfo; status =
> FltGetFileNameInformationUnsafe( FileObject, Instance,
> FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT,
&fileNameInfo
> );
>
> The stack was:
>
> f6602020 80abbf3e e1096958 00000360 81d414e8 nt!DbgBreakPoint f6602310
> 80abbf80 bbddbc12 bbddbbe2 00000204 nt!RtlAssert2+0x104 f660232c
> bbddbd23 bbddbc12 bbddbbe2 00000204 nt!RtlAssert+0x18 f6602350
bbddd464
> 81d414e8 00000360 00000000 fltmgr!FltpReallocNameControl+0x5f
> f6602378 bbde2690 81cf0a18 80abbf68 81d39f88
> fltmgr!FltpGetFileName+0x23e f6602390 bbdd6d82 81d39f88 80abbf68
> 81d39f88
> fltmgr!FltpGetOpenedFileName+0x92
> f66023ac bbde2c4e 81d39f88 80abbf68 81d39f88
> fltmgr!FltpCallOpenedFileNameHandler+0xdc
> f66023c8 bbde3dbb 81d39f88 00000000 81d39f88
> fltmgr!FltpGetNormalizedFileNameWorker+0x182
> f66023e4 bbdd9594 81d39f88 80abbf68 81cf07d0
> fltmgr!FltpGetNormalizedFileName+0x79
> f66023fc bbdd9b47 80aec000 00000000 81d39f88
> fltmgr!FltpCreateFileNameInformation+0x15e
> f6602414 bbda1344 81d39f88 81c0ee58 00000000
> fltmgr!CreateTemporaryFileNameInformation+0x8b
> f6602444 bbddb6fb 81d39f88 0000001a 81ca7760
> fltmgr!FltpGetFileNameInformation+0x138
> f6602468 f686490c 81c0ee58 81bf98a0 00000101
> fltmgr!FltGetFileNameInformationUnsafe+0x15d
> f66024a4 f6863ef0 e1a6a914 81cf04f8 81c0ee58
DeqoCPS!CpsPostOpenRec+0x9c
> f66024dc f6863855 81cf04f8 81c0ee58 81bf98a0
> DeqoCPS!CpsGetStreamContext+0x1b0 f660253c bbdf0033 81cd1464 f6602588
> f66025b8 DeqoCPS!CpsPreWrite+0x95
> f6602568 bbd896e6 00000001 00000004 f66025b8
> fltmgr!FltvPreOperation+0x3f
> f66025d4 bbd94e65 f6602620 00000000 83362fdc
> fltmgr!FltpPerformPreCallbacks+0x6a0
> f66025ec bbd97dee f6602620 00000000 81cf0960
> fltmgr!FltpPassThroughInternal+0xdb
> f6602608 bbd99255 83362f00 81cf0960 83362e28
> fltmgr!FltpPassThrough+0x584
>
> DeqoCPS is my mini-filter.
>
> “Molly Brown” wrote in message
> news:xxxxx@ntfsd…
> The FltGetFileName* APIs work with file names that are up to the file
> system limit. A name of 306 characters should be no problem. I
haven’t
> seen any similar problems in our internal testing of the filter
manager
> or of minifilters we’ve written.
>
> There is no ASSERT in filter manager that would check to ensure that a
> name is less than MAX_PATH. There are assertions at various places to
> check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
> being build is consistent - i.e., the total name length >= the volume
> name length, the total name length > the stream length, etc.
>
> If you could send me the exact message you are seeing, it would help
> figure out what is going on here.
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> 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 Ken Cross
> Sent: Tuesday, March 29, 2005 11:40 AM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Tony:
>
> Right. I’ve not seen a problem in my mini-filter – only in the
Windows
> API stuff I mentioned. I’m not sure where Mark is getting clobbered
but
> I haven’t used the specific routine he referenced
> (FltGetFileNameInformationUnsafe – sounds scary, huh?)
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
> Sent: Tuesday, March 29, 2005 2:27 PM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> If this limitation is present in the mini filter manager, that would
be
> a bug, however, because filter drivers have to be able to handle
things
> that might not work in the Win32 layer. For example, a system running
> SFU with a number of NFS clients would not be aware of this
> implementation decision within Win32. A product that breaks in such
an
> environment would be unacceptable as a commercial application (at
least
> as far as I’m concerned).
>
> I have no idea if this IS an issue with the mini-filter, but if so it
> needs to be reported and fixed. Filters MUST be able to work with
full
> sized path names, and names that are presented in other subsystems
> besides Win32.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems Class April
> 4, 2005 in Boston!
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
> Sent: Tuesday, March 29, 2005 2:14 PM
> To: ntfsd redirect
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Mark:
>
> In general, Windows chokes on any path > MAX_PATH (260) characters.
The
> Windows API has “several functions” where you can specify
> “\?\C:\path…”
> and get up to 32K characters. It also states that it’s possible to
> create paths (e.g., using relative paths) that cannot be accessed
> because their full path names would be too long.
>
> My experience has been that you’re stuck with the 260 character
maximum
> length path.
>
> HTH,
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Tuesday, March 29, 2005 2:00 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> I got an assertion in a call to FltGetFileNameInformationUnsafe that
> said the name was too long (unfortunately I forgot to save the error
> message).
> The length of the name in the file object was 306 characters so the
> total length was probably 323 chars. FltGetFileNameInformationUnsafe
> allocates it’s own memory for the structure so I cannot see anything I
> can do to fix this.
>
> Has anyone else had this problem? Does this mean I can’t use
> FltGetFileNameInformationUnsafe?
>
>
>
> —
> 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@osr.com 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: unknown lmsubst tag
argument:
> ‘’
> 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@windows.microsoft.com
> 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@osr.com 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: unknown lmsubst tag
argument:
> ‘’
> 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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks…
The problem has gone away in recent versions of my filter. If you really
care, let me know, and I’ll go back to the failing version, repeat the
problem, and generate the crash dump Molly requested.
I will switch to the safe version for all callback operations.
“Neal Christiansen” wrote in message
news:xxxxx@ntfsd…
Mark,
I am not quite sure what adding a spinlock was supposed to accomplish.
This is not a synchronization issue.
I have a couple of questions:
- What file system are you attached to?
- What other filters and minifilters are on the system? Specifically
below yours
- What frame is your filter in?
The query information operation will go below you so your filter will
not be involved with this. We need to know why we are getting a bad
length returned.
As a side question why are you calling the UNSAFE version of the naming
API. When processing an operation you should ONLY call the regular
version. The only reason for having the UNSAFE version is so filters
could query for names out-of-band of an operation, for example in a
worker thread unrelated to an operation
The reason to call the normal one from inside of an operation (and pass
in the callback data) is because the API knows when it is safe to query
the file system for the name. If it is not safe an error will be
returned. If you call the unsafe routine because of this limitation is
wrong because you will cause the system to deadlock periodically.
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 Mark Hahn
Sent: Tuesday, March 29, 2005 8:33 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
As I suspected, surrounding the call with a spin lock caused it to
bugchk.
“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> The only processing of IRP_MJ_QUERY_INFORMATION is this call to
> FltGetFileNameInformationUnsafe. I don’t see what I am doing wrong.
What
> should I try next? Could this be a re-entrancy problem? I’ll try
> protecting the call with a spin lock.
>
> “Molly Brown” wrote in message
> news:xxxxx@ntfsd…
> I think Tony is on to something here.
>
> The filter manager has just issued a IRP_MJ_QUERY_INFORMATION query
with
> the FileNameInformation information class. STATUS_BUFFER_OVERFLOW was
> returned, indicating that the buffer was not large enough. The file
> system should have returned the length needed to store the name in
> FileNameLength field of the FILE_NAME_INFORMATION structure passed
into
> the IRP_MJ_QUERY_INFORMATION.
>
> Filter manager builds up the new name buffer size based on the length
> based on the FILE_NAME_INFORMATION.FileNameLength plus the device name
> size and some padding for short name expansion. Since
> STATUS_BUFFER_OVERFLOW indicated that the original buffer size was too
> small, the new buffer size calculated from the
> FILE_NAME_INFORMATION.FileNameLength should always be larger than the
> original buffer size.
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> 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 Tony Mason
> Sent: Tuesday, March 29, 2005 5:35 PM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Does your filter do any processing of IRP_MJ_QUERY_INFORMATION? This
> assertion basically says “ensure the new allocation is bigger than the
> size of the current buffer” and the fact it fails is odd. One
possible
> cause of this is if you are trying to process a name request coming
from
> the underlying file system and not handling it properly.
>
> 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 Mark Hahn
> Sent: Tuesday, March 29, 2005 8:16 PM
> To: ntfsd redirect
> Subject: Re:[ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> I got the assertion error again. It looked like this:
>
> Assertion failed: NewSize > NameCtrl->BufferSize
> Source File: d:\xpsprtm\base\fs\filtermgr\filter\namesup.c, line
516
>
> The FileObject->FileName was: “\System Volume
>
Information_restore{387E7129-1274-4AFC-B9C8-5D596D9B45AB}\RP26\snapshot
> _REGISTRY_USER_NTUSER_S-1-5-21-1645522239-823518204-682003330-500”,
> which is 153 chars.
>
> My call was:
>
> PFLT_FILE_NAME_INFORMATION fileNameInfo; status =
> FltGetFileNameInformationUnsafe( FileObject, Instance,
> FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT,
&fileNameInfo
> );
>
> The stack was:
>
> f6602020 80abbf3e e1096958 00000360 81d414e8 nt!DbgBreakPoint f6602310
> 80abbf80 bbddbc12 bbddbbe2 00000204 nt!RtlAssert2+0x104 f660232c
> bbddbd23 bbddbc12 bbddbbe2 00000204 nt!RtlAssert+0x18 f6602350
bbddd464
> 81d414e8 00000360 00000000 fltmgr!FltpReallocNameControl+0x5f
> f6602378 bbde2690 81cf0a18 80abbf68 81d39f88
> fltmgr!FltpGetFileName+0x23e f6602390 bbdd6d82 81d39f88 80abbf68
> 81d39f88
> fltmgr!FltpGetOpenedFileName+0x92
> f66023ac bbde2c4e 81d39f88 80abbf68 81d39f88
> fltmgr!FltpCallOpenedFileNameHandler+0xdc
> f66023c8 bbde3dbb 81d39f88 00000000 81d39f88
> fltmgr!FltpGetNormalizedFileNameWorker+0x182
> f66023e4 bbdd9594 81d39f88 80abbf68 81cf07d0
> fltmgr!FltpGetNormalizedFileName+0x79
> f66023fc bbdd9b47 80aec000 00000000 81d39f88
> fltmgr!FltpCreateFileNameInformation+0x15e
> f6602414 bbda1344 81d39f88 81c0ee58 00000000
> fltmgr!CreateTemporaryFileNameInformation+0x8b
> f6602444 bbddb6fb 81d39f88 0000001a 81ca7760
> fltmgr!FltpGetFileNameInformation+0x138
> f6602468 f686490c 81c0ee58 81bf98a0 00000101
> fltmgr!FltGetFileNameInformationUnsafe+0x15d
> f66024a4 f6863ef0 e1a6a914 81cf04f8 81c0ee58
DeqoCPS!CpsPostOpenRec+0x9c
> f66024dc f6863855 81cf04f8 81c0ee58 81bf98a0
> DeqoCPS!CpsGetStreamContext+0x1b0 f660253c bbdf0033 81cd1464 f6602588
> f66025b8 DeqoCPS!CpsPreWrite+0x95
> f6602568 bbd896e6 00000001 00000004 f66025b8
> fltmgr!FltvPreOperation+0x3f
> f66025d4 bbd94e65 f6602620 00000000 83362fdc
> fltmgr!FltpPerformPreCallbacks+0x6a0
> f66025ec bbd97dee f6602620 00000000 81cf0960
> fltmgr!FltpPassThroughInternal+0xdb
> f6602608 bbd99255 83362f00 81cf0960 83362e28
> fltmgr!FltpPassThrough+0x584
>
> DeqoCPS is my mini-filter.
>
> “Molly Brown” wrote in message
> news:xxxxx@ntfsd…
> The FltGetFileName* APIs work with file names that are up to the file
> system limit. A name of 306 characters should be no problem. I
haven’t
> seen any similar problems in our internal testing of the filter
manager
> or of minifilters we’ve written.
>
> There is no ASSERT in filter manager that would check to ensure that a
> name is less than MAX_PATH. There are assertions at various places to
> check sure that the lengths of the FLT_FILE_NAME_INFORMATION structure
> being build is consistent - i.e., the total name length >= the volume
> name length, the total name length > the stream length, etc.
>
> If you could send me the exact message you are seeing, it would help
> figure out what is going on here.
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> 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 Ken Cross
> Sent: Tuesday, March 29, 2005 11:40 AM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Tony:
>
> Right. I’ve not seen a problem in my mini-filter – only in the
Windows
> API stuff I mentioned. I’m not sure where Mark is getting clobbered
but
> I haven’t used the specific routine he referenced
> (FltGetFileNameInformationUnsafe – sounds scary, huh?)
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
> Sent: Tuesday, March 29, 2005 2:27 PM
> To: Windows File Systems Devs Interest List
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> If this limitation is present in the mini filter manager, that would
be
> a bug, however, because filter drivers have to be able to handle
things
> that might not work in the Win32 layer. For example, a system running
> SFU with a number of NFS clients would not be aware of this
> implementation decision within Win32. A product that breaks in such
an
> environment would be unacceptable as a commercial application (at
least
> as far as I’m concerned).
>
> I have no idea if this IS an issue with the mini-filter, but if so it
> needs to be reported and fixed. Filters MUST be able to work with
full
> sized path names, and names that are presented in other subsystems
> besides Win32.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Looking forward to seeing you at the Next OSR File Systems Class April
> 4, 2005 in Boston!
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
> Sent: Tuesday, March 29, 2005 2:14 PM
> To: ntfsd redirect
> Subject: RE: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> Mark:
>
> In general, Windows chokes on any path > MAX_PATH (260) characters.
The
> Windows API has “several functions” where you can specify
> “\?\C:\path…”
> and get up to 32K characters. It also states that it’s possible to
> create paths (e.g., using relative paths) that cannot be accessed
> because their full path names would be too long.
>
> My experience has been that you’re stuck with the 260 character
maximum
> length path.
>
> HTH,
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
> Sent: Tuesday, March 29, 2005 2:00 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] FltGetFileNameInformationUnsafe assertion error
>
> I got an assertion in a call to FltGetFileNameInformationUnsafe that
> said the name was too long (unfortunately I forgot to save the error
> message).
> The length of the name in the file object was 306 characters so the
> total length was probably 323 chars. FltGetFileNameInformationUnsafe
> allocates it’s own memory for the structure so I cannot see anything I
> can do to fix this.
>
> Has anyone else had this problem? Does this mean I can’t use
> FltGetFileNameInformationUnsafe?
>
>
>
> —
> 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@osr.com 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: unknown lmsubst tag
argument:
> ‘’
> 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@windows.microsoft.com
> 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@osr.com 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: unknown lmsubst tag
argument:
> ‘’
> 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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com