NTFSD Folk:
The ParentDir returned from FltParseFileNameInformation() appears to have
changed when parsing a remote filename. Previously (a year or so ago), I’d
get this:
Name: \Device\LanmanRedirector\fkserver\vss\dir\x.c
Volume: \Device\LanmanRedirector
Share: \fkserver\vss
ParentDir: \fkserver\vss\dir\
Note that the share is included in ParentDir. This was contrary to the
documentation, but was what I got, so I handled it. Now I’m getting:
Name: \Device\LanmanRedirector\fkserver\vss\dir\x.c
Volume: \Device\LanmanRedirector
Share: \fkserver\vss
ParentDir: \dir\
This is consistent with the documentation, but it’s different than before.
Can somebody from Microsoft confirm that this was changed/fixed at some
point? What platforms and/or hotfixes are affected?
Are you there, Molly?
Ken
Aha, and I thought I was seeing things… I am almost certain it was the
documentation way long ago.
I think the recent Update of Filter Manager changed this.
http://support.microsoft.com/kb/922582/en-us
Ken Cross wrote:
NTFSD Folk:
The ParentDir returned from FltParseFileNameInformation() appears to have
changed when parsing a remote filename. Previously (a year or so ago), I’d
get this:
Name: \Device\LanmanRedirector\fkserver\vss\dir\x.c
Volume: \Device\LanmanRedirector
Share: \fkserver\vss
ParentDir: \fkserver\vss\dir\
Note that the share is included in ParentDir. This was contrary to the
documentation, but was what I got, so I handled it. Now I’m getting:
Name: \Device\LanmanRedirector\fkserver\vss\dir\x.c
Volume: \Device\LanmanRedirector
Share: \fkserver\vss
ParentDir: \dir\
This is consistent with the documentation, but it’s different than before.
Can somebody from Microsoft confirm that this was changed/fixed at some
point? What platforms and/or hotfixes are affected?
Are you there, Molly?
Ken
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
Great. That means we have to detect it and handle both cases.
This seems to work:
if( FileInfo.Share.Length > 0 &&
FileInfo.Share.Buffer == FileInfo.ParentDir.Buffer )
{
FileInfo.ParentDir.Buffer = Add2Ptr( FileInfo.ParentDir.Buffer,
FileInfo.Share.Length );
FileInfo.ParentDir.Length -= FileInfo.Share.Length;
}
Dear Microsoft:
This was tacky. Please let us know when you issue an update/hotfix that
breaks our stuff. Thanks.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Thursday, September 21, 2006 10:06 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Different behavior in FltParseFileNameInformation
Aha, and I thought I was seeing things… I am almost certain it was the
documentation way long ago.
I think the recent Update of Filter Manager changed this.
http://support.microsoft.com/kb/922582/en-us
Ken Cross wrote:
> NTFSD Folk:
>
> The ParentDir returned from FltParseFileNameInformation() appears to have
> changed when parsing a remote filename. Previously (a year or so ago),
I’d
> get this:
>
> Name: \Device\LanmanRedirector\fkserver\vss\dir\x.c
> Volume: \Device\LanmanRedirector
> Share: \fkserver\vss
> ParentDir: \fkserver\vss\dir<br>>
> Note that the share is included in ParentDir. This was contrary to the
> documentation, but was what I got, so I handled it. Now I’m getting:
>
> Name: \Device\LanmanRedirector\fkserver\vss\dir\x.c
> Volume: \Device\LanmanRedirector
> Share: \fkserver\vss
> ParentDir: \dir<br>>
> This is consistent with the documentation, but it’s different than before.
>
> Can somebody from Microsoft confirm that this was changed/fixed at some
> point? What platforms and/or hotfixes are affected?
>
> Are you there, Molly?
>
> Ken
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
–
King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
—
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
This caused a lot of grief for me from another point. When a certain antivirus is
installed with ours, the ParentDir.Length becomes ridiculously high on network share
access causing my filter to access invalid memory (yes, something is overwriting
memory, but I have crash dumps only from the third party system, and could not
reproduce it).
I was thinking along the same lines of comparing Buffer in order to know what to
add.
This change is rather nasty.
Ken Cross wrote:
Great. That means we have to detect it and handle both cases.
>
> This seems to work:
>
> if( FileInfo.Share.Length > 0 &&
> FileInfo.Share.Buffer == FileInfo.ParentDir.Buffer )
> {
> FileInfo.ParentDir.Buffer = Add2Ptr( FileInfo.ParentDir.Buffer,
> FileInfo.Share.Length );
> FileInfo.ParentDir.Length -= FileInfo.Share.Length;
> }
>
> Dear Microsoft:
>
> This was tacky. Please let us know when you issue an update/hotfix that
> breaks our stuff. Thanks.
–
King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.
This question has been asked before on the list:
http://www.osronline.com/showThread.cfm?link=73947
Since noone replied me, I asked Molly during IFS Plugfest #13 (a year ago)
to fix it. Next builds shouldn’t contain that bug.
workaround is actually compare ParentDir with Share (on
\LanmanRedirector) – I think it affects Win SP2 version of fltmgr.sys
Petr Kurtin
“Ken Cross” wrote in message news:xxxxx@ntfsd…
> NTFSD Folk:
>
> The ParentDir returned from FltParseFileNameInformation() appears to have
> changed when parsing a remote filename. Previously (a year or so ago),
> I’d
> get this:
>
> Name: \Device\LanmanRedirector\fkserver\vss\dir\x.c
> Volume: \Device\LanmanRedirector
> Share: \fkserver\vss
> ParentDir: \fkserver\vss\dir<br>>
> Note that the share is included in ParentDir. This was contrary to the
> documentation, but was what I got, so I handled it. Now I’m getting:
>
> Name: \Device\LanmanRedirector\fkserver\vss\dir\x.c
> Volume: \Device\LanmanRedirector
> Share: \fkserver\vss
> ParentDir: \dir<br>>
> This is consistent with the documentation, but it’s different than before.
>
> Can somebody from Microsoft confirm that this was changed/fixed at some
> point? What platforms and/or hotfixes are affected?
>
> Are you there, Molly?
>
> Ken
>
>