驱动程序中如何得到目录中的文件列表

我想得到目录中的文件列表
是不是先用目录路径创建一个文件对象，然后用zwcreatfile()打开
可是如果这者样，然后怎么办那？？
大侠指点一下了，多谢 :P

期待答案。

参见Native API：
ZwQueryDirectoryFile
具体用法就不用我说了吧？
网上有电子原版，书店有中文版。

谢谢，原来在IFS中啊

这么用为什么不对，返回代码是0X103,是什么意思？
到那里去查这个代码的定义呢？

file_names_information_buf = (PFILE_NAMES_INFORMATION)ExAllocatePool( NonPagedPool, sizeof(FILE_NAMES_INFORMATION) );


status1=ZwQueryDirectoryFile(
dir_handle,
NULL,
NULL,
NULL,
&In_Irp->IoStatus,
file_names_information_buf,
sizeof(FILE_NAMES_INFORMATION),
FileNamesInformation,
TRUE,
NULL,
TRUE
);

对了，问一下如何判断给定的一个路径是文件还是目录。

这个问题我也想知道，为什么没有人回答。

你的回答就是我想要的.

这是我的代码，设置FILE_INFORMATION_CLASS和PUNICODE_STRING 得到你想要的文件和目录。可能还有更好的方法

NTSYSAPI NTSTATUS NTAPI
ZwQueryDirectoryFile(
             IN HANDLE FileHandle,
             IN HANDLE Event OPTIONAL,
             IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
             IN PVOID ApcContext OPTIONAL,
             OUT PIO_STATUS_BLOCK IoStatusBlock,
             OUT PVOID FileInformation,
             IN ULONG Length,
             IN FILE_INFORMATION_CLASS FileInformationClass,
             IN BOOLEAN ReturnSingleEntry,
             IN PUNICODE_STRING FileName OPTIONAL,
             IN BOOLEAN RestartScan
             );
------------------------

#1 :
status = ZwCreateFile( &fileHandle,
                       GENERIC_READ,
                       &objectAttributes,
                       &IoStatus,
                       0,
                       FILE_ATTRIBUTE_DIRECTORY,
                       FILE_SHARE_READ | FILE_SHARE_WRITE |
FILE_SHARE_DELETE,
                       FILE_OPEN,
                       FILE_DIRECTORY_FILE,
                       NULL,
                       0 );

#2 :
status = ZwCreateEvent(&eventHandle, GENERIC_ALL, 0, NotificationEvent,
FALSE);

#3 :
status = ZwQueryDirectoryFile(fileHandle, eventHandle,0, 0, &Iosb,
Buffer, sizeof(Buffer),
                              FileBothDirectoryInformation, FALSE, NULL,
FALSE );
if (status == STATUS_PENDING)
   {
   status = ZwWaitForSingleObject(eventHandle, TRUE, 0);
   }


#4 :
DirInformation = (PFILE_BOTH_DIR_INFORMATION)Buffer;
for (;;)
    {
    UNICODE_STRING EntryName;
    EntryName.MaximumLength = EntryName.Length =
(USHORT)DirInformation->FileNameLength;

    EntryName.Buffer = &DirInformation->FileName[0];



    if (DirInformation->NextEntryOffset == 0)
       {
        break;
       }
    else
       {
       DirInformation =
(PFILE_BOTH_DIR_INFORMATION)(((PUCHAR)DirInformation) +
DirInformation->NextEntryOffset);
       }
     }

ZwClose(eventHandle);
ZwClose(fileHandle);

这些函数能在DDK中直接调用吗

在IFS中，你可以装一个，然后就可以调用了

是的，直接调用，但是你需要首先申明函数

是的，可以直接调用，声明结构和函数就可
在ISF的帮助中有说明

The determination of whether or not a given FILE_OBJECT represents a directory is the sole domain of the file system driver. Thus, for a file system filter driver to determine if a file is a directory, it must ask the file system. This can be done by querying the attributes of the file (e.g., after it has been successfully opened by the underlying file system) or by examining the attributes within the directory, which can be done before the underlying file has been opened.

Options specified during create are not adequate for determining if a file is, in fact, a directory. For example, an application may optionally specify that the file being opened must be a directory by setting the FILE_DIRECTORY_FILE option as part of create (this is a bit in the I/O Stack location, Parameters.Create.Options, the low 24 bits of which are used for file options). If the file creation is successful, the file system filter driver can conclude that the FILE_OBJECT does represent a directory. If the file creation is successful and the caller did not specify FILE_DIRECTORY_FILE, however, the caller cannot presume that the file is a directory. The FILE_NON_DIRECTORY_FILE bit can similarly be used to determine that the given FILE_OBJECT does not represent a file.

There is one complication for those writing a file system filter driver - they must keep in mind that some file options now combine these two bits. For example FILE_COPY_STRUCTURED_STORAGE (which is not used but is still present in ntifs.h for Windows XP) is defined as FILE_DIRECTORY_FILE and FILE_NON_DIRECTORY_FILE.

Thus, the safest way to determine if a FILE_OBJECT represents a directory remains to ask the underlying file system.

如何得到目录的内容：

In Windows XP, the function ZwQueryDirectoryFile is available for retrieving the contents of a directory using a file handle. Thus, this can be combined with ZwCreateFile to open a directory and retrieve its contents. The IFS Kit documentation describes how to use ZwQueryDirectoryFile in greater detail.

In versions prior to Windows XP, this routine is not documented. In all versions, it is possible to obtain the contents of a directory by utilizing the IRP_MJ_DIRECTORY_CONTROL operation, specifying IRP_MN_QUERY_DIRECTORY as the minor function code. This call passes in four parameters:

? Length - this is the length of the data buffer provided to the file system
? FileName - this is used for pattern matching against requests within the directory
? FileInformationClass - this is used to describe the format in which the data should be returned to the caller
? FileIndex - this is used to provide the location from which enumeration should take place (note that this is optional, as described later).

In addition, there are three flags in the I/O stack location that indicate the intention of this operation:

? SL_RESTART_SCAN - this indicates that the scan of the directory should be done relative to the first entry in the directory
? SL_RETURN_SINGLE_ENTRY - this indicates that at most one entry should be returned to the caller in the provided buffer
? SL_INDEX_SPECIFIED - this indicates that the FileIndex parameter was specified in the call and enumeration should begin with the entry specified by this index value.

Note that directory enumeration operations pass data back to the caller based upon the Flags field in the DEVICE_OBJECT structure of the file system driver. Thus, as is typical for a device driver, this will be METHOD_NEITHER and hence the Length parameter specifies the size of Irp->UserBuffer. As with any user level buffer access, this buffer may not be valid (of course, a kernel component making this call will specify RequestorMode in the IRP as KernelMode so that the buffer will be in the kernel address space). Typically, the FileName is only provided during the first call of the enumeration and the file system will store a copy of that data away for subsequent enumerations. If no name is presented, the enumeration will be treated as an enumeration of all entries in the directory. This is the equivalent of specifying \"*\" or \"*.*\" as the enumeration as well. While there are four different formats for the return data (FileDirectoryInformation, FileFullDirectoryInformation, FileBothDirectoryInformation, and FileNamesInformation) normally the preferred format is FileBothDirectoryInformation as this is the format requested by the Win32 subsystem when querying directories.

The file system will return a set of zero or more directories; the return value will indicate either an error (STATUS_BUFFER_OVERFLOW, STATUS_NO_SUCH_FILE, or STATUS_NO_MORE_FILES typically), or a success code (STATUS_SUCCESS or STATUS_PENDING). If STATUS_PENDING is returned, the caller can either block and wait or handle the results in a completion routine (which is safe for kernel mode components, since kernel addresses are valid in the completion routine context). The Information field will indicate the number of bytes returned after completion of the operation and the buffer will contain one (or more) entries from the directory.

This interface is stateful, so that a subsequent call will return additional information from the directory if it is available. When no further information is available, the file system will return STATUS_NO_MORE_FILES.