有关Filemon

在Filemon源码中有这样一个结构体
//
// Structure for the fileobject/name hash table
//
typedef struct _nameentry {
   PFILE_OBJECT FileObject;
   struct _nameentry *Next;
   CHAR FullPathName[];
} HASH_ENTRY, *PHASH_ENTRY;
它有什么作用》？

另外代码中的H A S H   T A B L E   M A N A G E M E N T
包含的函数FilemonHashCleanup、FilemonFreeHashEntry
有何作用？

如果不用这些，会有什么影响吗？

请各位大侠指点！

HASH_ENTRY是用来缓冲一些最近访问的文件，这样对于最近访问的文件，就不需要频繁的访问lower driver来得到文件名，提高效率。
可以看一下FilemonGetFullPath函数。
回答满意不，给分啊！

谢谢！
不过我不知道怎么给分啊
待我看看，：）

再问一个问题，
PATH AND PROCESS MANAGEMENT这部分的具体作用？不用这里面的函数有什么影响吗？

还有
如果直接去掉fast io部分，会对程序有影响吗？
（因为刚入门，对fast io还不了解）

我倒了。PATH AND PROCESS MANAGEMENT这一部分是处理文件名的，没有这部分，filemon有什么作用，罚你看三天源代码再来问。

哎！已经看了两天的源代码了
还有一堆的问题
还请高手多多指点啊

再问一次，
如果直接去掉fast io部分，会对程序有影响吗？

FilemonFastIoDeviceControl
最为重要，其余的你试试看去掉。
fastio是和cach打交道的。可以提高访问文件的效率。

3x!
我试过了，正像你说的，
除了FastIoDeviceControl不能去，其他的去掉不会有影响（当然只是从外部看）

fastio与cache打交道，在源码中，cache就是hash table吗？
NTSTATUS
FilemonDispatch(
    IN PDEVICE_OBJECT DeviceObject,
    IN PIRP Irp
    )
{
    //
    // Determine if its a request from the GUI to us, or one that is
    // directed at a file system driver that we\'ve hooked
    //
    if( ((PHOOK_EXTENSION) DeviceObject->DeviceExtension)->Type == GUIINTERFACE ) {

        return FilemonDeviceRoutine( DeviceObject, Irp );

    } else {

        return FilemonHookRoutine( DeviceObject, Irp );
    }
}
这部分一直不是很明白，总觉得FilemonDeviceRoutine和FilemonHookRoutine应该换一个位置，能解释一下吗?
谢谢！给分了

给你一段看看，关于fastio的
Q13 Must I support Fast I/O in my file system or filter, and where is Fast I/O documented?

 
    Fast I/O is optional for a file system. For a file system filter driver, it is required if any file system it filters supports fast I/O. Because all of the standard Windows NT/2000/XP file systems support fast I/O, essentially it is required of all filter drivers.

Fast I/O is a mechanism that was introduced into Windows NT in order to optimize the handling of certain I/O operations. In addition, fast I/O routines are also used for a variety of communications channels between the FSD and various kernel components, including the I/O Manager, the File System Runtime Library, and the CIFS File Server. Unfortunately, at the present time Fast I/O is not documented, although future versions of the IFS Kit will include documentation on how the Fast I/O routines are used.
 
hash table是用来缓冲文件名的，又说一次。

看看注释：
//
// Determine if its a request from the GUI to us, or one that is
// directed at a file system driver that we\'ve hooked
//

这下：
这部分一直不是很明白，总觉得FilemonDeviceRoutine和FilemonHookRoutine应该换一个位置，能解释一下吗?
谢谢！给分了

该懂了吧。

明白了！
：）

代码中的HookDriver和FilemonHookRoutine两个函数的作用有什么不同呢？

hookdrive是用来挂接c: d: 等盘符的。这样FilemonHookRoutine就可以截获所有的文件访问了。自己把源码看熟了。

修改了源代码DbgPrint()中的内容，为什么每次运行后
在DbgView中还是显示原来的内容？

呼呼，这下回答不了了，我还没有用过dbgview,调试时用的是softice。要学习！

还是很感谢你，给了我很多启发。
 :)

哪儿有源码？谢谢！

在IFS中，Types of I/O Requests That Are Sent to a Volume和Types of I/O Requests That Are Sent to a File System有很大的差别；反映在源码中，filemondeviceroutine中用的是Types of I/O Requests That Are Sent to a File System，而在filemonhookroutine中用的是Types of I/O Requests That Are Sent to a Volume
能不能帮忙解释一下？
感激不尽！！！

是这样的么，你好好看看。

难道我看错了？没有啊，的确是这样的，除了个别的。

另外，我想在IRP_MJ_CREATE时，通知应用程序，弹出身份验证的对话框，我是这样想的：先建立一个事件，让它在驱动部分挂起，
在FilemonHookRoutine中的
case IRP_MJ_CREATE:下，添加了如下代码：

KeSetEvent(Irp->UserEvent,2,FALSE);
Irp->IoStatus.Status=STATUS_PENDING；
Irp->IoStatus.Information=0;
IoMarkIrpPending(Irp);
hookExt->CreateIrp=Irp;
return STATUS_PENDING;
并且把LogRecord屏蔽了，

但是好像不起作用阿，在filemon中仍然能看到IRP_MJ_CREATE请求

TO nustzhua : 佩服 !

难道我看错了？没有啊，的确是这样的，除了个别的。

另外，我想在IRP_MJ_CREATE时，通知应用程序，弹出身份验证的对话框，我是这样想的：先建立一个事件，让它在驱动部分挂起，

 

呼呼，现在看来你不只是学来玩一玩了。下面是一些建议：
把事件的同步的处理好好研究研究；
不要害怕挫折。
其实你这样做也没有多大意义，在ntfs文件系统中有了安全特性，可以限制一个文件（目录）可以被那些用户使用。\"想在IRP_MJ_CREATE时，通知应用程序，弹出身份验证的对话框\"无非也就要达到这样的目的。
忘了说这个功能以前我也想去实现，但自从我知道了ntfs的安全特性之后，就没有这个想法了。：）
祝你好运!

TO nustzhua : 佩服 !

不用这么夸奖吧，呼呼。