怎样确定一个FileObject的类型是文件还是目录？

以前我们判断一个文件的类型时是按照Nt file systerm internals 上的方法，取IrpStack->parameters->options，与一些标志进行与来判断。 但我们发现
在ntfs系统上时，盘上的\\$Extend\\$Parse也会被判断成目录. 大家都清楚，这个文件是ntfs的系统文件.

除了向下发irp请求外，还有什么办法？
从已经有的信息，比如irpstack，fileobj能不能准备判断？

是否可以这样：在你的驱动中获得对象的名字，然后和界面交互，在界面中判断是否是文件还是目录。

这样肯定是不行的;) 效率太低

FileObject->FsContext->NodeTypeCode可以判断，不过这个值和文件系统类型相关，fat32,ntfs是不一样的，如果只支持这两个文件系统，可以跟踪一下看看，文件和目录对应的值是什么

FAT文件系统可以参考fastfat

fat 文件0x502      目录0x503
ntfs    0x0705           0x0703

fat还有根目录,ntfs也有根目录的,你的正确,但不全呀.

从源代码上看
ntfs跟fat32跟cdfs都使用

FsContext->NodeTypeCode
FsContext
FsContext2
三个一起作为判断某个file object是目录还是文件还是其他

但是这个办法并不是很好
天知道ms会不会在某个版本里面改变这些含义

大家再讨论一下怎么简单简便地在这儿确定文件系统类型.
比如ntfs/fat/cdfs/ufs

osr上关于这些的讨论,对后来者有用


Message 1 in thread
Subject: Still struggling with pFCB->Resource being 0xBBBBBBBB
From: Bartjan Wattel <xxx@zeelandnet.nl>
Date: Fri, 26 Oct 2001 12:01:09 +0200
 

Hi,

since two of the most valuable contributors of the NTFsd list are already
(or still ?) awake today, I thought I\'d throw in yet another brainbreaker.

I\'ve posted a question here earlier this week about getting the FCB from
FileObject->FsContext, and trying to acquire the pFCB->Resource. In a
specific case, the resource\'s value equals 0xBBBBBBBB.

So, here is some more information.

The strange value for the resource is already detected in the main \'hook\'
routine for the filter driver. The driver is attached to all available
DosDevices (\\\\DosDevice\\A: etc.) and to \\\\Device\\LanManRedirector. An IRP
(IRP_MJ_CREATE) comes in on the following DeviceObject (so this is in the
IRP_MJ_CREATE path, not on completion):

DeviceObject 8221C680
---------------------
     Type                   = 00000003
     Flags                  = 00000000
     Characteristics        = 00000000
     DeviceType             = 00000014
     DeviceType             = FILE_DEVICE_NETWORK_FILE_SYSTEM
     HookExtension          = 8221C738

Now, the FileObject in the current stack location has the following fields:

FileObject 821542E8
-------------------
     Type              5
     Size              112
     DeviceObject      82327A50
     Vpb               00000000
     FsContext         BCCE2ED4
     FsContext2        11444653
     FinalStatus       00000000
     RelatedFileObject 00000000
     Flags             00000002
     FileName
\\venus.thunderstore.local\\sysvol\\thunderstore.local\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}\\gpt.ini
     CurrentByteOffset 00000000
     Waiters           0
     Busy              0
     LastLock          00000000
     Lock              00040001
     Event             00040000

So a quick inspection of the
(PFSRTL_COMMON_FCB_HEADER)FileObject->FsContext shows me the following:

FCB BCCE2ED4
------------
     pFCB->NodeTypeCode     = 000000CA
     pFCB->NodeByteSize     = 000000CE
     pFCB->Flags            = 00000030
     pFCB->IsFastIoPossible = 0000002F
     pFCB->Flags2           = 000000CE
     pFCB->Reserved         = 000000BC
     pFCB->Resource         = BBBBBBBB
     pFCB->PagingIoResource = 00000001


Is this enough information for you to tell me what is happening ? Can we
trust the FCB content enough to state that the request concerns memory
mapped I/O (based on pFCB->Flags&0x20) ? Any other hints or tips to smash
this bug ?

Thanks again,
--
Bartjan Wattel.





Message 2 in thread
Subject: RE: Still struggling with pFCB->Resource being 0xBBBBBBBB
From: Tony Mason <xxx@osr.com>
Date: Fri, 26 Oct 2001 06:27:28 -0400
 

Bartjan,
 
First, I\'d note that there is nothing that REQUIRES a particular FSD to use
FSRTL_FCB_COMMON_HEADER (or, as they almost all do in XP, the ADVANCED
version, which just has extra fields at the end of it.)  So I suppose it is
possible that you have found some interesting file system that isn\'t using
the FsRtl library and hence isn\'t using the common header.  Or you\'ve found
some interesting path for memory corruption, or you\'ve found some path where
the file object isn\'t being fully created (there are a few odd cases where
the I/O manager \"fakes\" objects, actually...)
 
So, to make more sense of this question, I\'d want to know:
 
-          Which driver owns this device?
-          What does the stack look like at this point?
 
These may lead to a better understanding of why you are seeing this
particular combination.
 
Independent of the added information, what you are showing us does not look
like a common header structure to me.  The file object does not point back
to the device object you initially cited (is that your device object?  Or
the device object of the file system in question?)  The FsContext2 value is
quite clearly garbage.
 
Based on the name, the system is attempting to grab policy information (hmm.
I think that\'s domain policy information and not domain controller policy
information, based on the UUID in the name, but I know just enough about AD
to be dangerous.)  Thus, this is probably some OS mechanism grabbing the
policy so that it can apply it.  Dare I suggest it is some kernel mode
component attempting this?  Or perhaps this is the FRS - this isn\'t an
Active Directory server is it?
 
The only other thought is that RDR2 (or more likely RDBSS) is being tricky
here and storing information/data structure pointers that have nothing to do
with standard file system access.  Normally I\'d not suspect something like
that, but when it involves grabbing a group policy file (and the ini file at
that.)
 
Do you happen to have a nice kernel memory dump on this one.  This could
provide some interesting memory to grovel around.
 
Regards,
 
Tony
 
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com  
 
Sleep?  Who needs to sleep.  Someone I know has a T-shirt that sums it up
quite well - \"I\'ll sleep when I\'m dead.\" ;-)
 
 
-----Original Message-----
From: Bartjan Wattel [mailto:xxx@zeelandnet.nl]
Sent: Friday, October 26, 2001 6:01 AM
To: File Systems Developers
Subject: [ntfsd] Still struggling with pFCB->Resource being 0xBBBBBBBB
 
Hi,

since two of the most valuable contributors of the NTFsd list are already
(or still ?) awake today, I thought I\'d throw in yet another brainbreaker.

I\'ve posted a question here earlier this week about getting the FCB from
FileObject->FsContext, and trying to acquire the pFCB->Resource. In a
specific case, the resource\'s value equals 0xBBBBBBBB.

So, here is some more information.

The strange value for the resource is already detected in the main \'hook\'
routine for the filter driver. The driver is attached to all available
DosDevices (\\\\DosDevice\\A: etc.) and to \\\\Device\\LanManRedirector. An IRP
(IRP_MJ_CREATE) comes in on the following DeviceObject (so this is in the
IRP_MJ_CREATE path, not on completion):

DeviceObject 8221C680
---------------------
    Type                   = 00000003
    Flags                  = 00000000
    Characteristics        = 00000000
    DeviceType             = 00000014
    DeviceType             = FILE_DEVICE_NETWORK_FILE_SYSTEM
    HookExtension          = 8221C738

Now, the FileObject in the current stack location has the following fields:

FileObject 821542E8
-------------------
    Type              5
    Size              112
    DeviceObject      82327A50
    Vpb               00000000
    FsContext         BCCE2ED4
    FsContext2        11444653
    FinalStatus       00000000
    RelatedFileObject 00000000
    Flags             00000002
    FileName
\\venus.thunderstore.local\\sysvol\\thunderstore.local\\Policies\\{31B2F340-016D-
11D2-945F-00C04FB984F9}\\gpt.ini
    CurrentByteOffset 00000000
    Waiters           0
    Busy              0
    LastLock          00000000
    Lock              00040001
    Event             00040000

So a quick inspection of the (PFSRTL_COMMON_FCB_HEADER)FileObject->FsContext
shows me the following:

FCB BCCE2ED4
------------
    pFCB->NodeTypeCode     = 000000CA
    pFCB->NodeByteSize     = 000000CE
    pFCB->Flags            = 00000030
    pFCB->IsFastIoPossible = 0000002F
    pFCB->Flags2           = 000000CE
    pFCB->Reserved         = 000000BC
    pFCB->Resource         = BBBBBBBB
    pFCB->PagingIoResource = 00000001


Is this enough information for you to tell me what is happening ? Can we
trust the FCB content enough to state that the request concerns memory
mapped I/O (based on pFCB->Flags&0x20) ? Any other hints or tips to smash
this bug ?

Thanks again,
--
Bartjan Wattel.





Message 3 in thread
Subject: RE: Still struggling with pFCB->Resource being 0xBBBBBBBB
From: Bartjan Wattel <xxx@zeelandnet.nl>
Date: Fri, 26 Oct 2001 12:41:07 +0200
 

Tony,

 > Sleep?  Who needs to sleep.  Someone I know has a T-shirt that sums it up
 > quite well - \"I\'ll sleep when I\'m dead.\" ;-)

So I guess your *still* awake rather than *already* awake....

I\'ll send you a private email when I have the dump available.

Thanks a lot,
Bartjan.


At 06:27 26-10-2001 -0400, Tony Mason wrote:
>Bartjan,
>
>First, I\'d note that there is nothing that REQUIRES a particular FSD to use
>FSRTL_FCB_COMMON_HEADER (or, as they almost all do in XP, the ADVANCED
>version, which just has extra fields at the end of it.)  So I suppose it is
>possible that you have found some interesting file system that isn\'t using
>the FsRtl library and hence isn\'t using the common header.  Or you\'ve found
>some interesting path for memory corruption, or you\'ve found some path where
>the file object isn\'t being fully created (there are a few odd cases where
>the I/O manager \"fakes\" objects, actually...)
>
>So, to make more sense of this question, I\'d want to know:
>
>-          Which driver owns this device?
>-          What does the stack look like at this point?
>
>These may lead to a better understanding of why you are seeing this
>particular combination.
>
>Independent of the added information, what you are showing us does not look
>like a common header structure to me.  The file object does not point back
>to the device object you initially cited (is that your device object?  Or
>the device object of the file system in question?)  The FsContext2 value is
>quite clearly garbage.
>
>Based on the name, the system is attempting to grab policy information (hmm.
>I think that\'s domain policy information and not domain controller policy
>information, based on the UUID in the name, but I know just enough about AD
>to be dangerous.)  Thus, this is probably some OS mechanism grabbing the
>policy so that it can apply it.  Dare I suggest it is some kernel mode
>component attempting this?  Or perhaps this is the FRS - this isn\'t an
>Active Directory server is it?
>
>The only other thought is that RDR2 (or more likely RDBSS) is being tricky
>here and storing information/data structure pointers that have nothing to do
>with standard file system access.  Normally I\'d not suspect something like
>that, but when it involves grabbing a group policy file (and the ini file at
>that.)
>
>Do you happen to have a nice kernel memory dump on this one.  This could
>provide some interesting memory to grovel around.
>
>Regards,
>
>Tony
>
>Tony Mason
>Consulting Partner
>OSR Open Systems Resources, Inc.
>http://www.osr.com
>
>Sleep?  Who needs to sleep.  Someone I know has a T-shirt that sums it up
>quite well - \"I\'ll sleep when I\'m dead.\" ;-)
>
>
>-----Original Message-----
>From: Bartjan Wattel [mailto:xxx@zeelandnet.nl]
>Sent: Friday, October 26, 2001 6:01 AM
>To: File Systems Developers
>Subject: [ntfsd] Still struggling with pFCB->Resource being 0xBBBBBBBB
>
>Hi,
>
>since two of the most valuable contributors of the NTFsd list are already
>(or still ?) awake today, I thought I\'d throw in yet another brainbreaker.
>
>I\'ve posted a question here earlier this week about getting the FCB from
>FileObject->FsContext, and trying to acquire the pFCB->Resource. In a
>specific case, the resource\'s value equals 0xBBBBBBBB.
>
>So, here is some more information.
>
>The strange value for the resource is already detected in the main \'hook\'
>routine for the filter driver. The driver is attached to all available
>DosDevices (\\\\DosDevice\\A: etc.) and to \\\\Device\\LanManRedirector. An IRP
>(IRP_MJ_CREATE) comes in on the following DeviceObject (so this is in the
>IRP_MJ_CREATE path, not on completion):
>
>DeviceObject 8221C680
>---------------------
>     Type                   = 00000003
>     Flags                  = 00000000
>     Characteristics        = 00000000
>     DeviceType             = 00000014
>     DeviceType             = FILE_DEVICE_NETWORK_FILE_SYSTEM
>     HookExtension          = 8221C738
>
>Now, the FileObject in the current stack location has the following fields:
>
>FileObject 821542E8
>-------------------
>     Type              5
>     Size              112
>     DeviceObject      82327A50
>     Vpb               00000000
>     FsContext         BCCE2ED4
>     FsContext2        11444653
>     FinalStatus       00000000
>     RelatedFileObject 00000000
>     Flags             00000002
>     FileName
>\\venus.thunderstore.local\\sysvol\\thunderstore.local\\Policies\\{31B2F340-016D-
>11D2-945F-00C04FB984F9}\\gpt.ini
>     CurrentByteOffset 00000000
>     Waiters           0
>     Busy              0
>     LastLock          00000000
>     Lock              00040001
>     Event             00040000
>
>So a quick inspection of the (PFSRTL_COMMON_FCB_HEADER)FileObject->FsContext
>shows me the following:
>
>FCB BCCE2ED4
>------------
>     pFCB->NodeTypeCode     = 000000CA
>     pFCB->NodeByteSize     = 000000CE
>     pFCB->Flags            = 00000030
>     pFCB->IsFastIoPossible = 0000002F
>     pFCB->Flags2           = 000000CE
>     pFCB->Reserved         = 000000BC
>     pFCB->Resource         = BBBBBBBB
>     pFCB->PagingIoResource = 00000001
>
>
>Is this enough information for you to tell me what is happening ? Can we
>trust the FCB content enough to state that the request concerns memory
>mapped I/O (based on pFCB->Flags&0x20) ? Any other hints or tips to smash
>this bug ?
>
>Thanks again,
>--
>Bartjan Wattel.
>
>
>

发现有时取FsContext中的内容会导致错误

还是用irpstack->parameters->options中的判断
具体参见ifskit帮助中关于irp_mj_create 的选项。

有什么问题呀？
我这边好像没有呀！

你试一下，我的测试机上安装了ntfs,ntfs压缩，fat32

用这种方法不错，就是有时要判断一下能否取到值:)

不知道你是想在FS内部判断还是在FILTER中判断,一般来说:
ULONG RequestedOptions = 0;
BOOLEAN FileOnlyRequested = FALSE;
BOOLEAN DirectoryOnlyRequested =FALSE;

RequestedOptions = (IrpSp->Parameters.Create.Options & FILE_VALID_OPTION_FLAGS);
//是否为文件
FileOnlyRequested = ((RequestedOptions & FILE_NON_DIRECTORY_FILE) ? TRUE : FALSE);
//是否为目录
DirectoryOnlyRequested = ((RequestedOptions & FILE_DIRECTORY_FILE) ? TRUE : FALSE);

不过我TRACE了CDFS,发现其实这个值就不一定是对了,有时候系统发送的这个值是错误的,所以程序在进入目录或者文件的相关处理的时候还是要先判断一下是不是有问题,如果有问题就退出.比如你trace一下CDFS的对目录点击右键查看属性,其中就有把目录当成文件的请求.不知道是不是正确,或者有用,please check!

老狗-harmony soul

这种方法不正确，有时候是错误的。

用fscontext最准确，不过这在ms的官方文档上没有写。小心使用。

hehe,其实我说的在进入相关处理流程的时候再判断一次,就是用FsContext啊,他不就是FCB的指针吗.在FCB中程序本身肯定记录了他的确切属性.查一下就OK了.