How to stop Root Dir FileNameInfomation and other Frequesnt Request

This is follow-up question on my recent post. It was about the cycle of request that was occurring continuously even if the request completed continuously.So I investigated the request and response using File Test and File Spy. And Matched the response with NTFS partition. The output seems ok but still the it is being requested again and again.

Tony pointed out that the length of the buffer is too much but I want to clarify that the buffer size that is shown in the filespy is equal to the size of output buffer provided by the caller program.So the size of the buffer is not the problem.

I want help from the OSR community to understand this behaviour. Because there is no clue while would explorer make such kind of request when file system giving proper response.

POINT OF INTEREST IS THIS THAT IT IS HAPPENING WITH ROOT DIRECTORY ONLY.

FileNameInformation -> FsVolumeInformation -> FsAttributeInformation

Here is the code that showing How I am handling Request

FILENAME INFORMATION

ULONG Length = FIELD_OFFSET(FILE_NAME_INFORMATION, FileName);
Length += (PtrFCB->AbsoluteFileName.Length);
if (BufferSize >= Length)
{
PFILE_NAME_INFORMATION PtrInfo = (PFILE_NAME_INFORMATION)Irp->AssociatedIrp.SystemBuffer;
PtrInfo->FileNameLength = PtrFCB->AbsoluteFileName.Length;
RtlCopyMemory(PtrInfo->FileName, PtrFCB->AbsoluteFileName.Buffer, PtrFCB->AbsoluteFileName.Length);
Information = Length;
Status = STATUS_SUCCESS;
}
else
{
Information = 0;
Status = STATUS_BUFFER_OVERFLOW;
}

FsVoumeInformation

if (PtrIoStackLocation->Parameters.QueryVolume.Length < ((ULONG)FIELD_OFFSET(FILE_FS_VOLUME_INFORMATION, VolumeLabel[0]) + PtrVolume->VolumeName.Length))
{
Status = STATUS_BUFFER_OVERFLOW;
Information = FIELD_OFFSET(FILE_FS_VOLUME_INFORMATION, VolumeLabel[0]) + PtrVolume->VolumeName.Length;
break;
}
else
{
PFILE_FS_VOLUME_INFORMATION PtrVolumeInformation = Irp->AssociatedIrp.SystemBuffer;
PtrVolumeInformation->VolumeSerialNumber = 0X29051991;
PtrVolumeInformation->VolumeLabelLength = PtrVolume->VolumeName.Length;
PtrVolumeInformation->SupportsObjects = FALSE;
DEBUG_WUFS(“WUFS: VolName %wZ\n”,&PtrVolume->VolumeName);
RtlCopyMemory(PtrVolumeInformation->VolumeLabel, PtrVolume->VolumeName.Buffer, PtrVolume->VolumeName.Length);
PtrVolumeInformation->VolumeCreationTime.QuadPart = PtrVolume->CreationTime.QuadPart;
Status = STATUS_SUCCESS;
Information = (FIELD_OFFSET(FILE_FS_VOLUME_INFORMATION, VolumeLabel[0]) + PtrVolume->VolumeName.Length);
break;
}

FsAttributeInformation

if (PtrIoStackLocation->Parameters.QueryVolume.Length < sizeof(FILE_FS_ATTRIBUTE_INFORMATION))
{
Status = STATUS_BUFFER_OVERFLOW;
Information = (sizeof(FILE_FS_ATTRIBUTE_INFORMATION)+PtrVolume->VolumeName.Length);
break;
}
else
{

PFILE_FS_ATTRIBUTE_INFORMATION PtrFSAttribInformation = Irp->AssociatedIrp.SystemBuffer;
PtrFSAttribInformation->FileSystemAttributes = FILE_CASE_SENSITIVE_SEARCH |FILE_CASE_PRESERVED_NAMES | FILE_UNICODE_ON_DISK;
PtrFSAttribInformation->MaximumComponentNameLength = 255;
PtrFSAttribInformation->FileSystemNameLength = PtrVolume->VolumeName.Length;
DEBUG_WUFS(“WUFS: VolName %wZ\n”, &PtrVolume->VolumeName);
RtlCopyMemory(PtrFSAttribInformation->FileSystemName, PtrVolume->VolumeName.Buffer, PtrVolume->VolumeName.Length);
Status = STATUS_SUCCESS;
Information = (FIELD_OFFSET(FILE_FS_ATTRIBUTE_INFORMATION, FileSystemName[0]) + PtrVolume->VolumeName.Length);
break;
}

Tony’s point is that the returned length should be the length of the
returned buffer, not the length of the callers buffer. That said,
something is different n returning these requests. Have you confirmed no
other requests are being issued after this series which would cause the
loop to begin again?

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 4/29/2015 5:37:47 AM
Subject: [ntfsd] How to stop Root Dir FileNameInfomation and other
Frequesnt Request

>This is follow-up question on my recent post. It was about the cycle of
>request that was occurring continuously even if the request completed
>continuously.So I investigated the request and response using File Test
>and File Spy. And Matched the response with NTFS partition. The output
>seems ok but still the it is being requested again and again.
>
>Tony pointed out that the length of the buffer is too much but I want
>to clarify that the buffer size that is shown in the filespy is equal
>to the size of output buffer provided by the caller program.So the size
>of the buffer is not the problem.
>
>I want help from the OSR community to understand this behaviour.
>Because there is no clue while would explorer make such kind of request
>when file system giving proper response.
>
>POINT OF INTEREST IS THIS THAT IT IS HAPPENING WITH ROOT DIRECTORY
>ONLY.
>
>FileNameInformation -> FsVolumeInformation -> FsAttributeInformation
>
>Here is the code that showing How I am handling Request
>
>FILENAME INFORMATION
>================
>
> ULONG Length = FIELD_OFFSET(FILE_NAME_INFORMATION, FileName);
> Length += (PtrFCB->AbsoluteFileName.Length);
> if (BufferSize >= Length)
> {
> PFILE_NAME_INFORMATION PtrInfo =
>(PFILE_NAME_INFORMATION)Irp->AssociatedIrp.SystemBuffer;
> PtrInfo->FileNameLength = PtrFCB->AbsoluteFileName.Length;
> RtlCopyMemory(PtrInfo->FileName, PtrFCB->AbsoluteFileName.Buffer,
>PtrFCB->AbsoluteFileName.Length);
> Information = Length;
> Status = STATUS_SUCCESS;
> }
> else
> {
> Information = 0;
> Status = STATUS_BUFFER_OVERFLOW;
> }
>
>
>FsVoumeInformation
>==================
>if (PtrIoStackLocation->Parameters.QueryVolume.Length <
>((ULONG)FIELD_OFFSET(FILE_FS_VOLUME_INFORMATION, VolumeLabel[0]) +
>PtrVolume->VolumeName.Length))
> {
> Status = STATUS_BUFFER_OVERFLOW;
> Information = FIELD_OFFSET(FILE_FS_VOLUME_INFORMATION,
>VolumeLabel[0]) + PtrVolume->VolumeName.Length;
> break;
> }
> else
> {
> PFILE_FS_VOLUME_INFORMATION PtrVolumeInformation =
>Irp->AssociatedIrp.SystemBuffer;
> PtrVolumeInformation->VolumeSerialNumber = 0X29051991;
> PtrVolumeInformation->VolumeLabelLength =
>PtrVolume->VolumeName.Length;
> PtrVolumeInformation->SupportsObjects = FALSE;
> DEBUG_WUFS(“WUFS: VolName %wZ\n”,&PtrVolume->VolumeName);
> RtlCopyMemory(PtrVolumeInformation->VolumeLabel,
>PtrVolume->VolumeName.Buffer, PtrVolume->VolumeName.Length);
> PtrVolumeInformation->VolumeCreationTime.QuadPart =
>PtrVolume->CreationTime.QuadPart;
> Status = STATUS_SUCCESS;
> Information = (FIELD_OFFSET(FILE_FS_VOLUME_INFORMATION,
>VolumeLabel[0]) + PtrVolume->VolumeName.Length);
> break;
> }
>
>FsAttributeInformation
>==============
>if (PtrIoStackLocation->Parameters.QueryVolume.Length <
>sizeof(FILE_FS_ATTRIBUTE_INFORMATION))
> {
> Status = STATUS_BUFFER_OVERFLOW;
> Information =
>(sizeof(FILE_FS_ATTRIBUTE_INFORMATION)+PtrVolume->VolumeName.Length);
> break;
> }
> else
> {
>
> PFILE_FS_ATTRIBUTE_INFORMATION PtrFSAttribInformation =
>Irp->AssociatedIrp.SystemBuffer;
> PtrFSAttribInformation->FileSystemAttributes =
>FILE_CASE_SENSITIVE_SEARCH |FILE_CASE_PRESERVED_NAMES |
>FILE_UNICODE_ON_DISK;
> PtrFSAttribInformation->MaximumComponentNameLength = 255;
> PtrFSAttribInformation->FileSystemNameLength =
>PtrVolume->VolumeName.Length;
> DEBUG_WUFS(“WUFS: VolName %wZ\n”, &PtrVolume->VolumeName);
> RtlCopyMemory(PtrFSAttribInformation->FileSystemName,
>PtrVolume->VolumeName.Buffer, PtrVolume->VolumeName.Length);
> Status = STATUS_SUCCESS;
> Information = (FIELD_OFFSET(FILE_FS_ATTRIBUTE_INFORMATION,
>FileSystemName[0]) + PtrVolume->VolumeName.Length);
> break;
> }
>
>
>
>
>
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer

@Peter Tony Sir Pointed out the length from the FileSpy logs that i have posted earlier because filespy shows the callers buffer size not the legnth of the returned buffer how that can be a reason or a problem for something that can make this kind of behaviour.

In short i think Tony sir misinterprated the callers buffer size as the return return buffer size .

Now there is no reason why is this behaviour is happening.

One more thing what should i return when a filenameinformation queruy come when the file is opened as a OpenVolume (Fileobject.Filename.Length==0) . I think that could be the reason because I have filename '' for that…

This is the call stack that occuring every time any operation is perfomraed on my file system and cycle of this call stack has been noticed every time.EVen after completion of the request explorere again make the same request.

b9111ad4 814b98f3 89ae87b0 a4530b50 814b9871 AFSKernelMode!QueryInformationRoutine+0x17f [c:\users\ys_91_000\documents\visual studio 2013\projects\wufs\afskernelmode\afskernelmode\queryinformation.c @ 146]
b9111af8 81067a52 812810b1 a4530b50 89ae87b0 nt!IovCallDriver+0x82
b9111b0c 812810b1 446c69e0 00001408 12b0f320 nt!IofCallDriver+0x62
b9111bf8 8111a377 00001408 12b0f328 12b0f768 nt!NtQueryInformationFile+0x541
b9111bf8 77a92da4 00001408 12b0f328 12b0f768 nt!KiSystemServicePostCall
12b0f300 77a9142a 757df873 00001408 12b0f328 ntdll!KiFastSystemCallRet
12b0f304 757df873 00001408 12b0f328 12b0f768 ntdll!NtQueryInformationFile+0xa
12b0f980 757df80a 00000000 01164d08 00000000 KERNELBASE!IsThisARootDirectory+0xa3
12b0f9c4 763a2992 00001408 01164f26 00000105 KERNELBASE!GetVolumeInformationW+0xae
12b0f9ec 76345c26 0e338d78 12b0fa74 77a3ce0a SHELL32!CGetVolumeInformationParams::Call+0x39
12b0f9f8 77a3ce0a 01164d08 27dda111 010d21c4 SHELL32!Microsoft::WRL::Details::MakeAndInitialize,CAggregatableClassFactory >+0x82
12b0fa74 77a5a403 01164d08 0e338d78 27dda70d ntdll!RtlpTpWorkCallback+0xe6
12b0fc68 760b17ad 010d2d50 12b0fcb8 77a73af4 ntdll!TppWorkerThread+0x733
12b0fc74 77a73af4 010d2d50 27dda7dd 00000000 KERNEL32!BaseThreadInitThunk+0xe
12b0fcb8 77a73acd ffffffff 77aa42b4 00000000 ntdll!__RtlUserThreadStart+0x20
12b0fcc8 00000000 77a59cd0 010d2d50 00000000 ntdll!_RtlUserThreadStart+0x1b