Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

RETRIEVAL_POINTER_BASE

Jamey_KirbyJamey_Kirby Member - All Emails Posts: 428
typedef struct _RETRIEVAL_POINTER_BASE {
LARGE_INTEGER FileAreaOffset;
} RETRIEVAL_POINTER_BASE, *PRETRIEVAL_POINTER_BASE;


Is FileAreaOffset in bytes or sectors?

Comments

  • Alexandru_GurzouAlexandru_Gurzou Member Posts: 49
    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
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 428
    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
  • Alexandru_GurzouAlexandru_Gurzou Member Posts: 49
    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
    >
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 428
    It is my interpretation as well. It is how I have implemented it in my
    code. Maybe I am just brain-dead :) 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
  • Alex_GrigAlex_Grig Member Posts: 3,238
    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.
  • harald_brownharald_brown Member Posts: 109
    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
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 428
    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>;
    >
    > 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 <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • harald_brownharald_brown Member Posts: 109
    not of course, Lcn - this is in clusters, so need *SectorsPerAllocationUnit*BytesPerSector for convert to bytes
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 428
    Oh, I see


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

    > not of course, Lcn - this is in clusters, so need
    > *SectorsPerAllocationUnit*BytesPerSector for convert to bytes
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > 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 <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 428
    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
    >> *SectorsPerAllocationUnit*BytesPerSector for convert to bytes
    >>
    >> ---
    >> NTDEV is sponsored by OSR
    >>
    >> Visit the list online at: <
    >> http://www.osronline.com/showlists.cfm?list=ntdev>;
    >>
    >> 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 <
    >> http://www.osronline.com/page.cfm?name=ListServer>;
    >>
    >
  • Jamey_KirbyJamey_Kirby Member - All Emails Posts: 428
    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
    >>> *SectorsPerAllocationUnit*BytesPerSector for convert to bytes
    >>>
    >>> ---
    >>> NTDEV is sponsored by OSR
    >>>
    >>> Visit the list online at: <
    >>> http://www.osronline.com/showlists.cfm?list=ntdev>;
    >>>
    >>> 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 <
    >>> http://www.osronline.com/page.cfm?name=ListServer>;
    >>>
    >>
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA