FSCTL_GET_VOLUME_BITMAP subsequent calls

Hi All,
I am calling FSCTL_GET_VOLUME_BITMAP to get bitmap.

The return code is ERROR_MORE_DATA with lpBytesReturned 1024*1024. So what should be the STARTING_LCN_INPUT_BUFFER for next call?

LONGLONG GetVolumeBitmap(
HANDLE hDev, char* bitmap, LONGLONG startOffset) {
STARTING_LCN_INPUT_BUFFER sStartLcn;
sStartLcn.StartingLcn.QuadPart = startOffset; // 0 in first call
DWORD dwBitmapSize = 0;
DWORD dwAllocatedSize = 1024 * 1024;
VOLUME_BITMAP_BUFFER *pVolumeBitmap = NULL;
pVolumeBitmap = (VOLUME_BITMAP_BUFFER *)
LocalAlloc(LMEM_FIXED, dwAllocatedSize);

BOOL ret = DeviceIoControl(hDev,
FSCTL_GET_VOLUME_BITMAP,
&sStartLcn,
sizeof(sStartLcn),
pVolumeBitmap,
dwAllocatedSize,
&dwBitmapSize,
NULL);

So if this returns ret = 0 and GetLastError() = ERROR_MORE_DATA and dwBitmapSize = 1024*1024. So what should be the new LCN now?

From the MSDN documentation:

It says “…to retrieve the remaining bitmap”… so, you start with the NEXT LCN, I would think.

Or, you know, double the size of the buffer and call it again starting at zero :wink:

Peter
OSR
@OSRDrivers

> Or, you know, double the size of the buffer and call it again starting at
zero :wink:

Although not elegant, that is what I would do. I have to do the same when
getting retrieval pointers of a file.

On Tue, Jul 10, 2018 at 12:40 PM xxxxx@osr.com
wrote:

> From the MSDN documentation:
>
>


>
> It says “…to retrieve the remaining bitmap”… so, you start with the
> NEXT LCN, I would think.
>
> Or, you know, double the size of the buffer and call it again starting at
> zero :wink:
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
</http:>

And with a little math, you can figure out how large the buffer needs to be
for the entire volume (or pretty darn close).

On Tue, Jul 10, 2018 at 12:47 PM Jamey Kirby wrote:

> > Or, you know, double the size of the buffer and call it again starting
> at zero :wink:
>
> Although not elegant, that is what I would do. I have to do the same when
> getting retrieval pointers of a file.
>
> On Tue, Jul 10, 2018 at 12:40 PM xxxxx@osr.com
> wrote:
>
>> From the MSDN documentation:
>>
>>


>>
>> It says “…to retrieve the remaining bitmap”… so, you start with the
>> NEXT LCN, I would think.
>>
>> Or, you know, double the size of the buffer and call it again starting at
>> zero :wink:
>>
>> Peter
>> OSR
>> @OSRDrivers
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: <
>> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>
>
>
> –
> Jamey Kirby
> Disrupting the establishment since 1964
>
> This is a personal email account and as such, emails are not subject to
> archiving. Nothing else really matters.

>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
</http:>

> It says “…to retrieve the remaining bitmap”… so, you start with the NEXT
LCN, I would think.

How to get next LCN. That is exact question. I don’t want to double the buffer size.

>How to get next LCN

I’m sorry, but your question is not clear.

If you mean “How do I CALCULATE the next LCN” the answer is: You take the number of bytes returned to you and multiple by 8. That’s the NEXT LCN number.

Just for testing purposes, you can validate that you’re computing the next LCN correctly by retrieving the bitmap for a few clusters BEFORE that next LCN, and comparing the contents of the two buffers. That is, let’s say you get clusters 1 through 16 in your first request (you’ll get a lot more than this, but this is an example). You then get 17 through 32 in your SECOND request. You can validate that you’re calculating things correctly by retrieving the bitmap for clusters 8 through 24 and comparing the bits at the end of the first buffer you had previous retrieved and at the beginning of the second buffer you previously retrieved.

Hope that helps,

Peter
OSR
@OSRDrivers

Thanks Peter.

You take the number of bytes returned to you and multiple by 8. That’s the NEXT LCN number.

This is what I wanted, and it worked