NTSTATUS 0xc01c0018

NTFSD
1

Hi all:

I got this error when I tried to get a file path name in my minifilter driver. It occured in PreSetInformation of a file.

The code snippet:

if(FltObjects->FileObject) status = FltGetFileNameInformation( Data, FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &nameInfo ); else status = STATUS_UNSUCCESSFUL;if(!NT_SUCCESS(status) && FltObjects->FileObject) status = FltGetFileNameInformation( Data, FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP, &nameInfo );if(!NT_SUCCESS(status)) { ODS(DBG_FILE_EVENT, DBG_ERR, "%s: Failed to get file name %x", __FUNCTION__ , status); __leave; }

The file which caused the problem is a DTM log file in a DTM client machine: “\WTT\JobsWorkingDir\WTTSvc.log”

The error code is not documented anywhere. I’ve searched in DDK header files, OSR lists, Google/Google groups and MSDN but got nothing.

Does anybody know the meaning of this error value? Thanks a lot.

2

//
// MessageId: STATUS_FLT_NAME_CACHE_MISS
//
// MessageText:
//
// The name requested was not found in Filter Manager’s name cache and
could not be retrieved from the file system.
//
#define STATUS_FLT_NAME_CACHE_MISS ((NTSTATUS)0xC01C0018L)

from ntstatus.h

have a nice day,

Sandor LUKACS

xxxxx@ybwork.com wrote:

Hi all:

I got this error when I tried to get a file path name in my minifilter driver. It occured in PreSetInformation of a file.

The code snippet:

> if(FltObjects->FileObject)> status = FltGetFileNameInformation(> Data,> FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT,> &nameInfo> );> else> status = STATUS_UNSUCCESSFUL;>> if(!NT_SUCCESS(status) && FltObjects->FileObject)> status = FltGetFileNameInformation(> Data,> FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,> &nameInfo> );>> if(!NT_SUCCESS(status))> {> ODS(DBG_FILE_EVENT, DBG_ERR, "%s: Failed to get file name %x", __FUNCTION__ , status);> __leave;> }>>

The file which caused the problem is a DTM log file in a DTM client machine: “\WTT\JobsWorkingDir\WTTSvc.log”

The error code is not documented anywhere. I’ve searched in DDK header files, OSR lists, Google/Google groups and MSDN but got nothing.

Does anybody know the meaning of this error value? Thanks a lot.

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@bitdefender.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Yep. Just found that’s my fault to search with case-sensitive. :slight_smile:

But btw, with this error, how can we solve it? Thanks a lot.

4

xxxxx@ybwork.com wrote:

Yep. Just found that’s my fault to search with case-sensitive. :slight_smile:

But btw, with this error, how can we solve it? Thanks a lot.

I don’t know if a clean and always-working solution exists for
PreSetInformation. I would suggest to get the file name information on
the Create processing path, then store it in a stream context, and get
it every time you need (like in PreSetInformation). However, if you
decide to use this, then be sure to update the name information on file
renames.

Sandor LUKACS

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@bitdefender.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

That’s what I did in my legacy filter - I think minifilter doesn’t require this and remove it from there :slight_smile:

Another thing is, there is a FileName in FileObject and it has the path name of the file (I checked it with some tests). But not sure if this file name is always available in case of the failure of FltGetFileNameInformation.

6

xxxxx@ybwork.com wrote:

That’s what I did in my legacy filter - I think minifilter doesn’t require this and remove it from there :slight_smile:

Another thing is, there is a FileName in FileObject and it has the path name of the file (I checked it with some tests). But not sure if this file name is always available in case of the failure of FltGetFileNameInformation.

The FileName field from a FILE_OBJECT is only reliable on the create
path; you shall NEVER depend on it on any other I/O request processing
(like Read, Write, SetInformation and so on). To use that field it was
also a standard technique to store it into stream contexts on create,
then access it when you need later.

have a nice day,

Sandor LUKACS

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@bitdefender.com
To unsubscribe send a blank email to xxxxx@lists.osr.com