FSCTL_GET_RETRIEVAL_POINTERS doesn't work for small files

Hello All!

There is another problem with FSCTL_GET_RETRIEVAL_POINTERS. If I’m using
this IOCTL to receive LCNs for small files (I guess their size should be
less or equal to the cluster size - right?) the LCNs are always zero. Then I
have two questions:

  1. Where such a file is located physically on the volume?
  2. How to receive volume offsets to a file’s LCNs?

If the size of a file grows up to some file size threshold value it then
“appears” for the FSCTL_GET_RETRIEVAL_POINTERS and LCNs are non-zero.

Thanks, regards,

Mike

Are you seeing this problem on ntfs volumes?
Well I am not sure of, but smaller files on ntfs volumes gets stored with
the MFT Entry itself.
So this could be the reason that you are getting zero for smaller files.

Regards
Deepak

On Tue, May 12, 2009 at 11:48 PM, Mike Alekseev wrote:

> Hello All!
>
>
>
> There is another problem with FSCTL_GET_RETRIEVAL_POINTERS. If I?m using
> this IOCTL to receive LCNs for small files (I guess their size should be
> less or equal to the cluster size ? right?) the LCNs are always zero. Then I
> have two questions:
>
>
>
> 1. Where such a file is located physically on the volume?
> 2. How to receive volume offsets to a file?s LCNs?
>
>
>
> If the size of a file grows up to some file size threshold value it then
> ?appears? for the FSCTL_GET_RETRIEVAL_POINTERS and LCNs are non-zero.
>
>
>
> Thanks, regards,
>
> Mike
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>

Hi Deepak!

You are correct about NTFS. So if the file has small enough size to fit $MFT
entry then there is no chance to find it out through the
FSCTL_GET_RETRIEVAL_POINTERS?

Is there any solution for this issue? How do I know about the LCNs for such
small files?

Thanks, regards,

Mike


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Deepak Gupta
Sent: Tuesday, May 12, 2009 10:38 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] FSCTL_GET_RETRIEVAL_POINTERS doesn’t work for small
files

Are you seeing this problem on ntfs volumes?
Well I am not sure of, but smaller files on ntfs volumes gets stored with
the MFT Entry itself.
So this could be the reason that you are getting zero for smaller files.

Regards
Deepak

On Tue, May 12, 2009 at 11:48 PM, Mike Alekseev
wrote:

Hello All!

There is another problem with FSCTL_GET_RETRIEVAL_POINTERS. If I’m using
this IOCTL to receive LCNs for small files (I guess their size should be
less or equal to the cluster size - right?) the LCNs are always zero. Then I
have two questions:

1. Where such a file is located physically on the volume?
2. How to receive volume offsets to a file’s LCNs?

If the size of a file grows up to some file size threshold value it then
“appears” for the FSCTL_GET_RETRIEVAL_POINTERS and LCNs are non-zero.

Thanks, regards,

Mike


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other 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

Hi Mike,

I have never used FSCTLs.
Since file data is stored as resident attribute ($DATA is resident) with MFT
itself, So LCN would be equal to that of MFT entry’s LCN.
But again file data is stored on some offset (depending on attributes in MFT
entry). So that needs to be parsed.
May be FSCTL_GET_NTFS_FILE_RECORD is of your usage.
BTW why are you retrieving the pointers.

Regards
Deepak

On Wed, May 13, 2009 at 12:44 AM, Mike Alekseev wrote:

> Hi Deepak!
>
>
>
> You are correct about NTFS. So if the file has small enough size to fit
> $MFT entry then there is no chance to find it out through the FSCTL_GET_RETRIEVAL_POINTERS?
>
>
>
>
> Is there any solution for this issue? How do I know about the LCNs for such
> small files?
>
>
>
> Thanks, regards,
>
> Mike
>
>
> ------------------------------
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Deepak Gupta
> Sent: Tuesday, May 12, 2009 10:38 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] FSCTL_GET_RETRIEVAL_POINTERS doesn’t work for small
> files
>
>
>
> Are you seeing this problem on ntfs volumes?
> Well I am not sure of, but smaller files on ntfs volumes gets stored with
> the MFT Entry itself.
> So this could be the reason that you are getting zero for smaller files.
>
> Regards
> Deepak
>
> On Tue, May 12, 2009 at 11:48 PM, Mike Alekseev
> wrote:
>
> Hello All!
>
>
>
> There is another problem with FSCTL_GET_RETRIEVAL_POINTERS. If I?m using
> this IOCTL to receive LCNs for small files (I guess their size should be
> less or equal to the cluster size ? right?) the LCNs are always zero. Then I
> have two questions:
>
>
>
> 1. Where such a file is located physically on the volume?
> 2. How to receive volume offsets to a file?s LCNs?
>
>
>
> If the size of a file grows up to some file size threshold value it then
> ?appears? for the FSCTL_GET_RETRIEVAL_POINTERS and LCNs are non-zero.
>
>
>
> Thanks, regards,
>
> Mike
>
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other 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
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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
>

Hi Deepak!

I will try to use FSCTL_GET_NTFS_FILE_RECORD.

I need the LCNs to access files through the sectors in raw mode. I’m using
IDE PIO to read/write data.

Thanks, regards,

Mike


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Deepak Gupta
Sent: Wednesday, May 13, 2009 12:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] FSCTL_GET_RETRIEVAL_POINTERS doesn’t work for small
files

Hi Mike,

I have never used FSCTLs.
Since file data is stored as resident attribute ($DATA is resident) with MFT
itself, So LCN would be equal to that of MFT entry’s LCN.
But again file data is stored on some offset (depending on attributes in MFT
entry). So that needs to be parsed.
May be FSCTL_GET_NTFS_FILE_RECORD is of your usage.
BTW why are you retrieving the pointers.

Regards
Deepak

On Wed, May 13, 2009 at 12:44 AM, Mike Alekseev
wrote:

Hi Deepak!

You are correct about NTFS. So if the file has small enough size to fit $MFT
entry then there is no chance to find it out through the
FSCTL_GET_RETRIEVAL_POINTERS?

Is there any solution for this issue? How do I know about the LCNs for such
small files?

Thanks, regards,

Mike

_____

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Deepak Gupta
Sent: Tuesday, May 12, 2009 10:38 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] FSCTL_GET_RETRIEVAL_POINTERS doesn’t work for small
files

Are you seeing this problem on ntfs volumes?
Well I am not sure of, but smaller files on ntfs volumes gets stored with
the MFT Entry itself.
So this could be the reason that you are getting zero for smaller files.

Regards
Deepak

On Tue, May 12, 2009 at 11:48 PM, Mike Alekseev
wrote:

Hello All!

There is another problem with FSCTL_GET_RETRIEVAL_POINTERS. If I’m using
this IOCTL to receive LCNs for small files (I guess their size should be
less or equal to the cluster size - right?) the LCNs are always zero. Then I
have two questions:

1. Where such a file is located physically on the volume?
2. How to receive volume offsets to a file’s LCNs?

If the size of a file grows up to some file size threshold value it then
“appears” for the FSCTL_GET_RETRIEVAL_POINTERS and LCNs are non-zero.

Thanks, regards,

Mike


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other 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


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other 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

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other 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

>Where such a file is located physically on the volume?

They are resident within MFT itself, and their data stream share the same sector as their MFT record.

The notion of “disk blocks occupied by the file” is just not applicable for them.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>I need the LCNs to access files through the sectors in raw mode. I’m using IDE PIO to read/write data.

I can hardly imagine a requirement to do this for arbitrary files on the volume, I can only imagine a requirement to do this for some special files of your product.

But, if you have this strange a requirement, I would strongly consider writing your own NTFS parser.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com