An application sets a reparse point on a file with tag IO_REPARSE_TAG_DEDUP. And I have mini filter driver in which we try to open file ADS(alternate data stream) with fltcreatefile(), it should return status_object_name_not_found as by this time ADS does not exist for this file but it returns status_io_reparse_tag_not_handled. Let me explain with an example :
Suppose file path is C:\dir\file and in minifilter driver we try to open C:\dir\file:personal by this time it does not exist so usually it returns status_object_name_not_found but here it returns status_io_reparse_tag_not_handled. What I think is happening as we pass the request to target instance down the stack and upper minifilter driver might be handling this tag so upper minifilter driver is not getting chance to handle this tag because the request is going down not to the topmost stack, right ?
Here is the fltcreatefile call :
// Open helper file object
Status = FltCreateFile(pMountInfo->Filter,
pMountInfo->TargetInstance,
&FileHandle,
(option == INODE_IO_OVERWRITE ? FILE_APPEND_DATA : 0) | \
(option == INODE_IO_DELETE ? DELETE : 0) | \
FILE_READ_DATA|FILE_WRITE_DATA|SYNCHRONIZE,
&ObjectAttributes,
&IoStatus,
0,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_VALID_FLAGS,
FILE_OPEN,
(option == INODE_IO_DELETE ? FILE_DELETE_ON_CLOSE : 0) | \
FILE_WRITE_THROUGH | \
FILE_SYNCHRONOUS_IO_NONALERT | \
FILE_RANDOM_ACCESS,
NULL,
0,
IO_IGNORE_SHARE_ACCESS_CHECK
);
“upper minifilter driver might be handling this tag” - you have special filter in system which handle IO_REPARSE_TAG_DEDUP by self ? windows not handled IO_REPARSE_TAG_DEDUP . in IopfCompleteRequest exist next code:
if ((Irp->IoStatus.Status == STATUS_REPARSE ) &&
(Irp->IoStatus.Information > IO_REPARSE_TAG_RESERVED_RANGE)) {
switch (Irp->IoStatus.Information)
{
case IO_REPARSE_TAG_MOUNT_POINT:
case IO_REPARSE_TAG_SYMLINK:
saveAuxiliaryPointer = Irp->Tail.Overlay.AuxiliaryBuffer;
Irp->Tail.Overlay.AuxiliaryBuffer = 0;
break;
default:
Irp->IoStatus.Status = STATUS_IO_REPARSE_TAG_NOT_HANDLED;// your case
}
}
so you and must got STATUS_IO_REPARSE_TAG_NOT_HANDLED on file with IO_REPARSE_TAG_DEDUP
On 07/11/2016 03:08 AM, xxxxx@gmail.com wrote:
An application sets a reparse point on a file with tag IO_REPARSE_TAG_DEDUP. And I have mini filter driver in which we try to open file ADS(alternate data stream) with fltcreatefile(), it should return status_object_name_not_found as by this time ADS does not exist for this file but it returns status_io_reparse_tag_not_handled.
It’s hard to know without more context, but this might be a good time to
open the reparse point itself using FILE_OPEN_REPARSE_POINT. If this
alternate stream open is happening because the user already has a handle
to the file itself, you probably intended to look for the stream on the
file the user has opened, not some other file by a reparse point
redirection.
For dedup specifically, note that the reparse tag does not redirect to
another file, so it would be quite common for user handles to exist to
these files.
@robert - No we don’t have any specific filter driver that handles this case. Are you saying that if I would have send this request to up the stack then still I would have got this error in return ?
If I Open the same file C:\dir\file using filetest utility then I am seeing status_status to the application. But internally in my filter driver through PostCreate I try to open stream file for this file then I see this error in return.
@Malcolm - User has opened file as I said in PostCreate I am trying to open stream file then I see the error.
if you have no specific filter driver that handles this case - windows by self return STATUS_IO_REPARSE_TAG_NOT_HANDLED if you try open file with IO_REPARSE_TAG_DEDUP and without FILE_OPEN_REPARSE_POINT option in CreateFile call.