sfilter的NLGetFullPathName得到短名?

为什么我在wdk的sfilter ,sfcreate中 NLGetFullPathName有时会得到\Docume~1\user\locals~1\之类的短名?
有人遇到同样的情况吗?
谢谢!

unresolved external symbol _NLAllocateNameControl@8 referenced in function _FsTPMCreateRoutine@8

借用宝地.
请问这个错误是什么原因

楼上的,你的sfilter源码不全.需要namelookup库.新版的sfilter带

不大懂 我的 namelookup.h 文件是这样子的

不知道什么原因

/*++

Copyright (c) 2004  Microsoft Corporation

Module Name:

    namelookup.h

Abstract:

    Header file containing the name lookup device extension and name lookup
    function prototypes.


Environment:

    Kernel mode

--*/

#ifndef __NAMELOOKUP_H__
#define __NAMELOOKUP_H__

#include "namelookupdef.h"

//
//  Give pointer alignment characteristics for the different processor types
//

#if defined(_X86_)
#   define DECLSPEC_PTRALIGN __declspec(align(4))
#elif defined(_AMD64_)
#   define DECLSPEC_PTRALIGN __declspec(align(8))
#elif defined(_IA64_)
#   define DECLSPEC_PTRALIGN __declspec(align(8))
#else
#   error "No target architecture defined"
#endif

//
//  These structures are used to retrieve the name of objects.  To prevent
//  allocating memory every time we get a name, and to prevent having large
//  string buffers on the stack, this structure contains a small
//  buffer (which should handle 90+% of all names).  If we do overflow this
//  buffer we will allocate a buffer big enough for the name.
//

typedef struct _NAME_CONTROL {

    //
    //  UNICODE_STRING whos buffer is either SmallBuffer or AllocatedBuffer
    //  if a larger buffer was needed.
    //

    UNICODE_STRING Name;

    //
    //  AllocatedBuffer is used when we need a buffer larger than SmallBuffer.
    //

    PUCHAR AllocatedBuffer;

    //
    //  The size of whatever buffer is currently being used (SmallBuffer or
    //  AllocatedBuffer) in bytes.
    //

    ULONG BufferSize;

    //
    //  This is the buffer that we start out with.  The thinking is that this
    //  should be large enough for most names.
    //

    DECLSPEC_PTRALIGN UCHAR SmallBuffer[254];

} NAME_CONTROL, *PNAME_CONTROL;


//
//  NL_EXTENSION is the part of a device extension that is needed
//  by the name lookup routines.  All the non-namelookup data contained
//  here should be needed by any filter.  Simply use this as part of
//  any filter's device extension.
//

typedef struct _NL_DEVICE_EXTENSION_HEADER {

    //
    //  Device Object this device extension is attached to
    //

    PDEVICE_OBJECT ThisDeviceObject;

    //
    //  Device object this filter is directly attached to
    //

    PDEVICE_OBJECT AttachedToDeviceObject;

    //
    //  When attached to Volume Device Objects, the physical device object
    //  that represents that volume.  NULL when attached to Control Device
    //  objects.
    //

    PDEVICE_OBJECT StorageStackDeviceObject;

    //
    //  DOS representation of the device name.
    //

    UNICODE_STRING DosName;

    //
    //  Name for this device.  If attached to a Volume Device Object it is the
    //  name of the physical disk drive.  If attached to a Control Device
    //  Object it is the name of the Control Device Object.  This is in the
    //  "\Device\...\" format.
    //

    UNICODE_STRING DeviceName;

} NL_DEVICE_EXTENSION_HEADER, *PNL_DEVICE_EXTENSION_HEADER;



/////////////////////////////////////////////////////////////////////////////
//
//  Name lookup functions.
//
/////////////////////////////////////////////////////////////////////////////

NTSTATUS
NLGetFullPathName (
    IN PFILE_OBJECT FileObject,
    IN OUT PNAME_CONTROL FileNameControl,
    IN PNL_DEVICE_EXTENSION_HEADER NLExtHeader,
    IN NAME_LOOKUP_FLAGS LookupFlags,
    IN PPAGED_LOOKASIDE_LIST LookasideList,
    OUT PBOOLEAN CacheName
    );

PNAME_CONTROL
NLGetAndAllocateObjectName (
    IN PVOID Object,
    IN PPAGED_LOOKASIDE_LIST LookasideList
    );

NTSTATUS
NLGetObjectName (
    IN PVOID Object,
    IN OUT PNAME_CONTROL ObjectNameCtrl
    );

VOID
NLGetDosDeviceName (
    IN PDEVICE_OBJECT DeviceObject,
    IN PNL_DEVICE_EXTENSION_HEADER NLExtHeader
    );

/////////////////////////////////////////////////////////////////////////////
//
//  General support routines
//
/////////////////////////////////////////////////////////////////////////////

NTSTATUS
NLAllocateAndCopyUnicodeString (
    IN OUT PUNICODE_STRING DestName,
    IN PUNICODE_STRING SrcName,
    IN ULONG PoolTag
    );

/////////////////////////////////////////////////////////////////////////////
//
//  Name lookup device extension header functions.
//
/////////////////////////////////////////////////////////////////////////////

VOID
NLInitDeviceExtensionHeader (
    IN PNL_DEVICE_EXTENSION_HEADER NLExtHeader,
    IN PDEVICE_OBJECT ThisDeviceObject,
    IN PDEVICE_OBJECT StorageStackDeviceObject
    );

VOID
NLCleanupDeviceExtensionHeader(
    IN PNL_DEVICE_EXTENSION_HEADER NLExtHeader
    );

/////////////////////////////////////////////////////////////////////////////
//
//  Routines to support generic name control structures that allow us
//  to get names of arbitrary size.
//
/////////////////////////////////////////////////////////////////////////////
NTSTATUS
NLAllocateNameControl (
    OUT PNAME_CONTROL *NameControl,
    IN PPAGED_LOOKASIDE_LIST LookasideList
    );

VOID
NLFreeNameControl (
    IN PNAME_CONTROL NameControl,
    IN PPAGED_LOOKASIDE_LIST LookasideList
    );

NTSTATUS
NLCheckAndGrowNameControl (
    IN OUT PNAME_CONTROL NameCtrl,
    IN USHORT NewSize
    );

VOID
NLInitNameControl (
    IN PNAME_CONTROL NameCtrl
    );

VOID
NLCleanupNameControl (
    IN PNAME_CONTROL NameCtrl
    );

NTSTATUS
NLReallocNameControl (
    IN PNAME_CONTROL NameCtrl,
    IN ULONG NewSize,
    OUT PWCHAR *RetOriginalBuffer OPTIONAL
    );

#endif

namelookup.h 里面函数是如何实现的呢

在create irp完成后取文件名可以避免这个问题，2k ntfs需要特殊处理。

引用第5楼tooflat于2007-06-26 23:51发表的  :
在create irp完成后取文件名可以避免这个问题，2k ntfs需要特殊处理。

但是有很多情况是需要在create之前来做类似与deny的动作
（因为cancel post IRP_MJ_CREATE异常复杂），所以。。。

咋都不回答楼主的问题呢:(

自己层层解析为长名。