Mailslots and FltGetFileNameInformation()

NTFSD
1

I’m invoking FltGetFileNameInformation() (using FLT_FILE_NAME_NORMALIZED
and FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP specified in
NameOptions) in my post-create callback and get a return code of
STATUS_FLT_INVALID_NAME_REQUEST. The file object related to this
request happens to be a mailslot (“\admin*\MAILSLOT\NET\NETLOGON”).
From a past posting in the group, it was suggested to use
FLT_FILE_NAME_OPENED instead of FLT_FILE_NAME_NORMALIZED when the file
object is associated with a mail slot. I was trying to determine,
possibly in my pre-create callback, when the request was for the open of
a mail slot instead of a file; I was going to check the major IRP code
in the callback data structure, but that is always zero (0) in both the
pre- and post-operation callbacks. I did notice that
FsContext/FsContext2 were both NULL in the post-create callback. Any
idea how I can distinguish a create for a file vs pipe vs mailslot in my
create callback(s)?

I’m using the checked version of the Filter Manager on XP and built the
minifilter with WDK 5270 if that makes a difference.

thanks

2

Have you tried checking for FO_MAILSLOT in the FileObject Flags?

It’s not clear if you’re trying to handle mailslots or avoid them. If you
want to avoid them completely, just check for DEVICE_TYPE ==
FILE_DEVICE_MAILSLOT in your instance setup and return
STATUS_FLT_DO_NOT_ATTACH.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vossen, Joseph (ISS
Atlanta)
Sent: Friday, February 10, 2006 2:22 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Mailslots and FltGetFileNameInformation()

I’m invoking FltGetFileNameInformation() (using FLT_FILE_NAME_NORMALIZED
and FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP specified in
NameOptions) in my post-create callback and get a return code of
STATUS_FLT_INVALID_NAME_REQUEST. The file object related to this
request happens to be a mailslot (“\admin*\MAILSLOT\NET\NETLOGON”).
From a past posting in the group, it was suggested to use
FLT_FILE_NAME_OPENED instead of FLT_FILE_NAME_NORMALIZED when the file
object is associated with a mail slot. I was trying to determine,
possibly in my pre-create callback, when the request was for the open of
a mail slot instead of a file; I was going to check the major IRP code
in the callback data structure, but that is always zero (0) in both the
pre- and post-operation callbacks. I did notice that
FsContext/FsContext2 were both NULL in the post-create callback. Any
idea how I can distinguish a create for a file vs pipe vs mailslot in my
create callback(s)?

I’m using the checked version of the Filter Manager on XP and built the
minifilter with WDK 5270 if that makes a difference.

thanks

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

3

> Have you tried checking for FO_MAILSLOT in the FileObject Flags?

I never see this set for a file object that represents a mail slot. In
each case, the file object’s flag is 0x2.

It’s not clear if you’re trying to handle mailslots or avoid
them. If you want to avoid them completely, just check for
DEVICE_TYPE == FILE_DEVICE_MAILSLOT in your instance setup
and return STATUS_FLT_DO_NOT_ATTACH.

I’m trying to avoid them; thanks for reminding me that I have this info
at instance setup time. However, I never see this situation in my
instance setup routine. When I load my filter, I am invoked three (3)
times at my instance setup (automatic attachment) with the following
values:

DEVICE_TYPE FLT_FILE_SYSTEM_TYPE

FILE_DEVICE_NETWORK_FILE_SYSTEM (0x14) FLT_FSTYPE_WEBDAV (0x7)
FILE_DEVICE_NETWORK_FILE_SYSTEM (0x14) FLT_FSTYPE_LANMAN (0x6)
FILE_DEVICE_DISK_FILE_SYSTEM (0x8) FLT_FSTYPE_NTFS (0x2)

And my instance setup is never called again (i.e. I never receive an
instance setup callback where DEVICE_TYPE == FILE_DEVICE_MAILSLOT).

Thanks