FSCTL_GET_VOLUME_BITMAP can be a tricky FSCTL for first time use. In particular the output buffer can be interpretted incorrectly. If your output buffer is not big enough to handle all the requested information you will receive ERROR_MORE_DATA as your return code (as you would expect).
The common mistake is to interpret VOLUME_BITMAP_BUFFER::BitmapSize as the number of clusters covered in the output buffer. However this is not the case. This member variable describes the number of cluster left in the volume from your startin LCN that you passed into the call. The # of valid clusters needs to be calculated from lpBytesReturned. The calculation would be as follows:
The common mistake is to interpret VOLUME_BITMAP_BUFFER::BitmapSize as the number of clusters covered in the output buffer. However this is not the case. This member variable describes the number of cluster left in the volume from your startin LCN that you passed into the call. The # of valid clusters needs to be calculated from lpBytesReturned. The calculation would be as follows:
ULONG clusters = lpBytesReturned - FIELD_OFFSET(VOLUME_BITMAP_BUFFER, Buffer);
clusters *= 8;
I personally don't like this implementation because it is easy to get this wrong and typically an API which returns ERROR_MORE_DATA with a member describing the # of bytes actually needed suggests that the output data is only valid in its full form. Obviously a bitmap does not fit into this category.
arigato ..............................
ReplyDelete