RETRIEVAL_POINTER_BASE

typedef struct _RETRIEVAL_POINTER_BASE {
LARGE_INTEGER FileAreaOffset;
} RETRIEVAL_POINTER_BASE, *PRETRIEVAL_POINTER_BASE;

Is FileAreaOffset in bytes or sectors?

Um, isn’t this actually specified in the documentation?
https://msdn.microsoft.com/en-us/library/windows/desktop/dd405530(v=vs.85).aspx

On 8 January 2016 at 23:48, Jamey Kirby wrote:

> typedef struct _RETRIEVAL_POINTER_BASE {
> LARGE_INTEGER FileAreaOffset;
> } RETRIEVAL_POINTER_BASE, *PRETRIEVAL_POINTER_BASE;
>
>
> Is FileAreaOffset in bytes or sectors?
>
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at

It is not clear to me. It says sector offset. Is that a byte offset or a
count of sectors? in this case, offset is not clear. Usually offset is used
in the context of bytes, and counts are specified as count. But, i is not
clear to me.

In reviewing diskcryptor on Git hub, the developer assumes it is a sector
count, and multiplies the offset by sector size before doing IO. I do this
in my driver too. However, the documentation is not clear. I wanted
clarification. I guess it is easy enough to break out the hex editor and
look at the disk. But, since it was unclear to me, maybe posting on NTDEV
would get some clarification for me, and help others in the future.
Obviously I read the documentation.
*FileAreaOffset*

The volume-relative sector offset to the first allocatable unit on the file
system, also referred to as the base of the cluster heap.

On Sat, Jan 9, 2016 at 3:34 AM Gurzou Alexandru
wrote:

> Um, isn’t this actually specified in the documentation?
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd405530(v=vs.85).aspx
>
> On 8 January 2016 at 23:48, Jamey Kirby wrote:
>
>> typedef struct _RETRIEVAL_POINTER_BASE {
>> LARGE_INTEGER FileAreaOffset;
>> } RETRIEVAL_POINTER_BASE, *PRETRIEVAL_POINTER_BASE;
>>
>>
>> Is FileAreaOffset in bytes or sectors?
>>
>>
>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
>> on crash dump analysis, WDF, Windows internals and software drivers!
>> Details at To unsubscribe, visit the List Server section of OSR Online
>> at
>
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at

Well, I can’t understand anything else than offset in sectors no matter how
many times I read the documentation and see “sector offset”.

Sorry if I offended you, that wasn’t my intention but I really thought you
somehow missed the documentation.

On 9 January 2016 at 17:32, Jamey Kirby wrote:

> It is not clear to me. It says sector offset. Is that a byte offset or a
> count of sectors? in this case, offset is not clear. Usually offset is used
> in the context of bytes, and counts are specified as count. But, i is not
> clear to me.
>
> In reviewing diskcryptor on Git hub, the developer assumes it is a sector
> count, and multiplies the offset by sector size before doing IO. I do this
> in my driver too. However, the documentation is not clear. I wanted
> clarification. I guess it is easy enough to break out the hex editor and
> look at the disk. But, since it was unclear to me, maybe posting on NTDEV
> would get some clarification for me, and help others in the future.
> Obviously I read the documentation.
> FileAreaOffset
>
> The volume-relative sector offset to the first allocatable unit on the
> file system, also referred to as the base of the cluster heap.
>
>
> On Sat, Jan 9, 2016 at 3:34 AM Gurzou Alexandru <
> xxxxx@gmail.com> wrote:
>
>> Um, isn’t this actually specified in the documentation?
>> https://msdn.microsoft.com/en-us/library/windows/desktop/dd405530(v=vs.85).aspx
>>
>> On 8 January 2016 at 23:48, Jamey Kirby wrote:
>>
>>> typedef struct _RETRIEVAL_POINTER_BASE {
>>> LARGE_INTEGER FileAreaOffset;
>>> } RETRIEVAL_POINTER_BASE, *PRETRIEVAL_POINTER_BASE;
>>>
>>>
>>> Is FileAreaOffset in bytes or sectors?
>>>
>>>
>>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY
>>> seminars on crash dump analysis, WDF, Windows internals and software
>>> drivers! Details at To unsubscribe, visit the List Server section of
>>> OSR Online at
>>
>>
>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
>> on crash dump analysis, WDF, Windows internals and software drivers!
>> Details at To unsubscribe, visit the List Server section of OSR Online
>> at
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at
>

It is my interpretation as well. It is how I have implemented it in my
code. Maybe I am just brain-dead :slight_smile: No mater how many times I read, it, it
is unclear to me.Had I written the documentation, I would have been more
clear; something like “Offset in number of sectors …”.Maybe even in the
code this: FileAreaStartingSector

On Sat, Jan 9, 2016 at 10:54 AM Gurzou Alexandru
wrote:

> Well, I can’t understand anything else than offset in sectors no matter
> how many times I read the documentation and see “sector offset”.
>
> Sorry if I offended you, that wasn’t my intention but I really thought you
> somehow missed the documentation.
>
> On 9 January 2016 at 17:32, Jamey Kirby wrote:
>
>> It is not clear to me. It says sector offset. Is that a byte offset or a
>> count of sectors? in this case, offset is not clear. Usually offset is used
>> in the context of bytes, and counts are specified as count. But, i is not
>> clear to me.
>>
>> In reviewing diskcryptor on Git hub, the developer assumes it is a sector
>> count, and multiplies the offset by sector size before doing IO. I do this
>> in my driver too. However, the documentation is not clear. I wanted
>> clarification. I guess it is easy enough to break out the hex editor and
>> look at the disk. But, since it was unclear to me, maybe posting on NTDEV
>> would get some clarification for me, and help others in the future.
>> Obviously I read the documentation.
>> FileAreaOffset
>>
>> The volume-relative sector offset to the first allocatable unit on the
>> file system, also referred to as the base of the cluster heap.
>>
>>
>> On Sat, Jan 9, 2016 at 3:34 AM Gurzou Alexandru <
>> xxxxx@gmail.com> wrote:
>>
>>> Um, isn’t this actually specified in the documentation?
>>> https://msdn.microsoft.com/en-us/library/windows/desktop/dd405530(v=vs.85).aspx
>>>
>>> On 8 January 2016 at 23:48, Jamey Kirby wrote:
>>>
>>>> typedef struct _RETRIEVAL_POINTER_BASE {
>>>> LARGE_INTEGER FileAreaOffset;
>>>> } RETRIEVAL_POINTER_BASE, *PRETRIEVAL_POINTER_BASE;
>>>>
>>>>
>>>> Is FileAreaOffset in bytes or sectors?
>>>>
>>>>
>>>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY
>>>> seminars on crash dump analysis, WDF, Windows internals and software
>>>> drivers! Details at To unsubscribe, visit the List Server section of
>>>> OSR Online at
>>>
>>>
>>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY
>>> seminars on crash dump analysis, WDF, Windows internals and software
>>> drivers! Details at To unsubscribe, visit the List Server section of
>>> OSR Online at
>>
>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
>> on crash dump analysis, WDF, Windows internals and software drivers!
>> Details at To unsubscribe, visit the List Server section of OSR Online
>> at
>>
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at

It looks like it may return not offset in sectors, but offset in clusters.

"Remarks

Adding the value retrieved by FSCTL_GET_RETRIEVAL_POINTER_BASE to the value retrieved by the FSCTL_GET_RETRIEVAL_POINTERS control code results in a volume-relative file extent offset."

FSCTL_GET_RETRIEVAL_POINTERS returns LCNs - logical cluster numbers.

i do test - it return offset as count of sectors, not clusters. so calculate like this:
FILE_FS_SIZE_INFORMATION ffsi;
RETRIEVAL_POINTER_BASE _rpb;
PRETRIEVAL_POINTERS_BUFFER prpb;
LARGE_INTEGER ByteOffset;
ByteOffset.QuadPart = (prpb->Extents[n].Lcn.QuadPart*ffsi.SectorsPerAllocationUnit + _rpb.FileAreaOffset.QuadPart) * ffsi.BytesPerSector;

however on NTFS always 0 in FileAreaOffset, only on FAT not zero

Shouldn’t it be:

ByteOffset.QuadPart = (prpb->Extents[n].Lcn.QuadPart *
ffsi.SectorsPerAllocationUnit) + (_rpb.FileAreaOffset.QuadPart *
ffsi.BytesPerSector)

;

On Sat, Jan 9, 2016 at 4:51 PM wrote:

> i do test - it return offset as count of sectors, not clusters. so
> calculate like this:
> FILE_FS_SIZE_INFORMATION ffsi;
> RETRIEVAL_POINTER_BASE _rpb;
> PRETRIEVAL_POINTERS_BUFFER prpb;
> LARGE_INTEGER ByteOffset;
> ByteOffset.QuadPart =
> (prpb->Extents[n].Lcn.QuadPart*ffsi.SectorsPerAllocationUnit +
> _rpb.FileAreaOffset.QuadPart) * ffsi.BytesPerSector;
>
> however on NTFS always 0 in FileAreaOffset, only on FAT not zero
>
> —
> 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;
></http:>

not of course, Lcn - this is in clusters, so need *SectorsPerAllocationUnit*BytesPerSector for convert to bytes

Oh, I see

On Sat, Jan 9, 2016 at 6:39 PM wrote:

> not of course, Lcn - this is in clusters, so need
> SectorsPerAllocationUnitBytesPerSector for convert to bytes
>
> —
> 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;
></http:>

Hmmm… I am going to run some tests.

On Sun, Jan 10, 2016 at 12:42 AM Jamey Kirby wrote:

> Oh, I see
>
>
> On Sat, Jan 9, 2016 at 6:39 PM wrote:
>
>> not of course, Lcn - this is in clusters, so need
>> SectorsPerAllocationUnitBytesPerSector for convert to bytes
>>
>> —
>> 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;
>>
></http:>

For sure the value is in sectors. Using trusty WinHex, I reviewed several
FAT formats with various cluster sizes. Walked some FAT entries, and came
to the proper conclusion. As for the math, it is six one way, a half a
dozen the other. Offsets are offsets. You can calculate them the easy way,
or the hard way. (Lcn * ClusterSIze) == Offset1. (FatDataOffset *
SectorSize) == Offset2. Offset1 + Offset2 == correct offset. There is no
need to convert Lcn to sectors before doing the addition; you can skip that
and proceed to adding the offsets.

On Sun, Jan 10, 2016 at 1:00 AM Jamey Kirby wrote:

> Hmmm… I am going to run some tests.
>
> On Sun, Jan 10, 2016 at 12:42 AM Jamey Kirby
> wrote:
>
>> Oh, I see
>>
>>
>> On Sat, Jan 9, 2016 at 6:39 PM wrote:
>>
>>> not of course, Lcn - this is in clusters, so need
>>> SectorsPerAllocationUnitBytesPerSector for convert to bytes
>>>
>>> —
>>> 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;
>>>
>></http:>