RE: FltGetFileNameInformation() returns INVALID_DEVICE_REQUEST for named

Hi Molly,

These create request are always completed with SUCCESS, so this seems to be
not consistent with previous comments in the list about NORMALIZED name.

In post-create, after the create has been completed by the FS succesfully, i
fail to obtain the name for these PIPES and MAILSLOTS. The failure code for
FltObjects->FileObject.FileName == \misha*\MAILSLOT\NET\NETLOGON is
STATUS_FLT_INVALID_NAME_REQUEST and the failure code for
FltObjects->FileObject.FileName == \misha\PIPE\wkssvc is
STATUS_INVALID_DEVICE_REQUEST. This status are the same that in pre-create.

Accidentally I have observed that in post-create FileObject->Flags contains
FO_NAMED_PIPE for the named pipe but it doesn´t specify FO_MAILSLOT for the
succesfylly opened MAILSLOT. Is this correct?

Thanks,
mK

From the archives:

“If you ever find that a name query for a normalized name from the filter
manager fails but the open succeeds please let us know about this because it
should never happen and we would want to figure out what happened. Of
course as Molly said this would not apply if an out-of-memory error was
returned.” Neal Christiansen

From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when requesting
a NORMALIZED name in pre-CREATE, it means that the CREATE operation is going
to fail because the name is not valid.  When you request a NORMALIZED name,
the Filter Manager needs to take the same steps a legacy filter needs to do
today to ensure that each component in the path has been expanded to its
long form.  Therefore, Filter Manager iterates through the components in the
path, checks if it could be a DOS name, and if so, opens the parent
directory and queries for FileNamesInformation.  If the name provided isn’t
valid, Filter Manager will get an error in that processing and return it to
the caller.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Molly Brown
Sent: Monday, February 21, 2005 8:29 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation() returns
INVALID_DEVICE_REQUEST for named pipes.

The filter manager sends the operation to the callback specified by the
IRP_MJ code in the original IRP. If you are seeing a name containing
“\PIPE”, I would expect that this is because the IRP sent to filter manager
also specified IRP_MJ_CREATE. I’d expect this CREATE to fail since it is
for a named pipe and not a file. In precreate, the name has not yet been
validated by the file system, so there is nothing preventing the user from
sending down an invalid name.

You cannot normalize a named pipe name. Try requesting the name with
FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT instead.

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 Misha Karpin
Sent: Monday, February 21, 2005 7:35 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation() returns INVALID_DEVICE_REQUEST
for named pipes.

Hi,

Which is the intended use for IRP_MJ_CREATE_NAMED_PIPE in filter manager
model?.

When i filter IRP_MJ_CREATE for LanMan redirector i usually see
\misha\PIPE\srvsvc and \misha\PIPE\wkssvc in
FltObjects->FileObject->FileName during preCreateCallback. For these
FileObjects FltGetFileNameInformation() returns
STATUS_INVALID_DEVICE_REQUEST in pre-create. Parameters for this call are
(FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT).

Is FltGetFileNameInformation() behavior the expected one for these
fileobjects?. Why i see these named pipe creation in IRP_MJ_CREATE when
there is a IRP_MJ_CREATE_NAMED_PIPE? Is there any other mode to detect named
pipe creation in pre-create apart from string comparison with \PIPE?

Thanks,
mK


Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

I did some more research and it turns out I was wrong to expect the named pipe and mailslot requests to fail. You will see named pipes and mailslots come through the regular IRP_MJ_CREATE path since that is how you open an existing named pipe or mailslot. The IRP_MJ_CREATE_NAMED_PIPE/IRP_MJ_CREATE_MAILSLOT are for truly creating these objects.

Mailslots do not support name queries, so that is why you are getting back STATUS_FLT_INVALID_NAME_REQUEST.

If you are still trying to query the NORMALIZED name, I believe that is your problem. Named pipes support name queries, but they do not support the operations needed to normalize a name - namely opening each component in the path and quering to see if it has a long name. Queries for the OPENED name should succeed. I overlooked the named pipe and mailslot cases in my earlier posting that you reference below.

The Lanman redirector does not set the FO_MAILSLOT flag in its fileobject that represent opens of mailslots.

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 Misha Karpin
Sent: Tuesday, February 22, 2005 2:00 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation() returns INVALID_DEVICE_REQUEST for named

Hi Molly,

These create request are always completed with SUCCESS, so this seems to be not consistent with previous comments in the list about NORMALIZED name.

In post-create, after the create has been completed by the FS succesfully, i fail to obtain the name for these PIPES and MAILSLOTS. The failure code for
FltObjects->FileObject.FileName == \misha*\MAILSLOT\NET\NETLOGON is
STATUS_FLT_INVALID_NAME_REQUEST and the failure code for
FltObjects->FileObject.FileName == \misha\PIPE\wkssvc is
STATUS_INVALID_DEVICE_REQUEST. This status are the same that in pre-create.

Accidentally I have observed that in post-create FileObject->Flags contains
FO_NAMED_PIPE for the named pipe but it doesn?t specify FO_MAILSLOT for the
succesfylly opened MAILSLOT. Is this correct?

Thanks,
mK

From the archives:

“If you ever find that a name query for a normalized name from the filter
manager fails but the open succeeds please let us know about this because it
should never happen and we would want to figure out what happened. Of
course as Molly said this would not apply if an out-of-memory error was
returned.” Neal Christiansen

From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when requesting
a NORMALIZED name in pre-CREATE, it means that the CREATE operation is going
to fail because the name is not valid.? When you request a NORMALIZED name,
the Filter Manager needs to take the same steps a legacy filter needs to do
today to ensure that each component in the path has been expanded to its
long form.? Therefore, Filter Manager iterates through the components in the
path, checks if it could be a DOS name, and if so, opens the parent
directory and queries for FileNamesInformation.? If the name provided isn’t
valid, Filter Manager will get an error in that processing and return it to
the caller.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Molly Brown
Sent: Monday, February 21, 2005 8:29 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation() returns
INVALID_DEVICE_REQUEST for named pipes.

The filter manager sends the operation to the callback specified by the
IRP_MJ code in the original IRP. If you are seeing a name containing
“\PIPE”, I would expect that this is because the IRP sent to filter manager
also specified IRP_MJ_CREATE. I’d expect this CREATE to fail since it is
for a named pipe and not a file. In precreate, the name has not yet been
validated by the file system, so there is nothing preventing the user from
sending down an invalid name.

You cannot normalize a named pipe name. Try requesting the name with
FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT instead.

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 Misha Karpin
Sent: Monday, February 21, 2005 7:35 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation() returns INVALID_DEVICE_REQUEST
for named pipes.

Hi,

Which is the intended use for IRP_MJ_CREATE_NAMED_PIPE in filter manager
model?.

When i filter IRP_MJ_CREATE for LanMan redirector i usually see
\misha\PIPE\srvsvc and \misha\PIPE\wkssvc in
FltObjects->FileObject->FileName during preCreateCallback. For these
FileObjects FltGetFileNameInformation() returns
STATUS_INVALID_DEVICE_REQUEST in pre-create. Parameters for this call are
(FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT).

Is FltGetFileNameInformation() behavior the expected one for these
fileobjects?. Why i see these named pipe creation in IRP_MJ_CREATE when
there is a IRP_MJ_CREATE_NAMED_PIPE? Is there any other mode to detect named
pipe creation in pre-create apart from string comparison with \PIPE?

Thanks,
mK


Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


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