In testing my driver, I used shift-del in explorer to delete a file
immediately instead of going to the recycle bin. My driver called
dFltGetFileNameInformationUnsafe using the code below and got a very strange
path/name for the file:
status = FltGetFileNameInformationUnsafe( compCtx->FileObject,
InstanceCtx->Instance, FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP, &compCtx->FileNameInfo );
The name returned was: “\System Volume
Information_restore{854F999C-6839-4B46-9A6C-8F59ECA012B9}\RP13\A0006111.cmd”
I know the fileobject was for my deleted file because the
PCFLT_RELATED_OBJECTS->FileObject matched an earlier rename with the correct
name.
Any idea why this would happen? It is possible I had the wrong fileobject
of course, but the code for that has been tested throroughly.
Never mind. I got fooled again by a call not returning anything in a buffer
and looking at old contents. Sorry for the wasted post.
“Mark Hahn” wrote in message news:xxxxx@ntfsd…
> In testing my driver, I used shift-del in explorer to delete a file
> immediately instead of going to the recycle bin. My driver called
> dFltGetFileNameInformationUnsafe using the code below and got a very
> strange path/name for the file:
>
> status = FltGetFileNameInformationUnsafe( compCtx->FileObject,
> InstanceCtx->Instance, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP, &compCtx->FileNameInfo );
>
> The name returned was: “\System Volume
> Information_restore{854F999C-6839-4B46-9A6C-8F59ECA012B9}\RP13\A0006111.cmd”
>
> I know the fileobject was for my deleted file because the
> PCFLT_RELATED_OBJECTS->FileObject matched an earlier rename with the
> correct name.
>
> Any idea why this would happen? It is possible I had the wrong fileobject
> of course, but the code for that has been tested throroughly.
>
>