Prev: USB Storage Device Detetcion
Next: Volume Shadow Copy Service Restore Operation
From: Matt on 2 Jun 2010 22:42
Hi,

I'm writing some code that reads the FileName attribute file records from
the MFT by using the FSCTL_GET_NTFS_FILE_RECORD api call.

I've noticed that, for most records, the DataSize, AllocatedSize and
LastWriteTime are accurate when compared to the values in the win explorer
file properties dialog. However, for some more recent files/records the size
values are always 0 and the timestamp is incorrect.

Has anyone experienced this issue? I'm hoping to gain an understanding
of how/when NFTS updates the record with the correct values.

Thanks.

--
Matt
From: David Lowndes on 3 Jun 2010 04:19
>I'm writing some code that reads the FileName attribute file records from
>the MFT by using the FSCTL_GET_NTFS_FILE_RECORD api call.
>
>I've noticed that, for most records, the DataSize, AllocatedSize and
>LastWriteTime are accurate when compared to the values in the win explorer
>file properties dialog. However, for some more recent files/records the size
>values are always 0 and the timestamp is incorrect.
>
>Has anyone experienced this issue? I'm hoping to gain an understanding
>of how/when NFTS updates the record with the correct values.

Matt,

FWIW, there is a note in the FindFirstFile API documentation that
mentions something that may be related to what you're seeing:

"Note In rare cases, file information on NTFS file systems may not be
current at the time you call this function. To be assured of getting
the current file information, call the GetFileInformationByHandle
function."

Dave
From: Matt on 7 Jun 2010 23:44

Dave,

Thanks for the response. I was afraid that GetFileInformationByHandle would
be the answer. :) That will certainly work but is an inefficient solution for
cases where a large number of files need to be read. I'm hoping to find a way
of ensuring that the MFT FileAttribute timestamps and sizes are accurate.
There must be a trigger somewhere.

I agree with the FindFirstFile API documentation except for the word 'rare'.
I can make this situation happen consistently and have reproduced on Windows
XP, Windows 7 and Windows 2003. Here's the scenario:

The MFT FileAttribute will have timestamps and sizes of 0 for any file that
is created as empty, then opened, populated with data and written. What's
more, when I rename the file and read the MFT, the timestamps and dates show
up correctly. It seems that the NTFS/Kernel has a trigger that fires on a
rename but doesn't fire when a file that was initially empty is written.

In searching for a trigger to remedy the situation, I've tried reading the
MFT after rebooting, powercycling and running vzshadow & mounting a
persistent shadow copy. Unfortunately, no luck. :(

Hoping that you can help.

Thanks,

Note: All timestamp and size comparisons mentioned are between the MFT
FileAttribute and the Windows File Properties dialog.
--
Matt


"David Lowndes" wrote:

> >I'm writing some code that reads the FileName attribute file records from
> >the MFT by using the FSCTL_GET_NTFS_FILE_RECORD api call.
> >
> >I've noticed that, for most records, the DataSize, AllocatedSize and
> >LastWriteTime are accurate when compared to the values in the win explorer
> >file properties dialog. However, for some more recent files/records the size
> >values are always 0 and the timestamp is incorrect.
> >
> >Has anyone experienced this issue? I'm hoping to gain an understanding
> >of how/when NFTS updates the record with the correct values.
>
> Matt,
>
> FWIW, there is a note in the FindFirstFile API documentation that
> mentions something that may be related to what you're seeing:
>
> "Note In rare cases, file information on NTFS file systems may not be
> current at the time you call this function. To be assured of getting
> the current file information, call the GetFileInformationByHandle
> function."
>
> Dave
> .
>
From: David Lowndes on 11 Jun 2010 19:09

>Hoping that you can help.

Unfortunately I don't know the solution :(

Dave
 | 
Pages: 1
Prev: USB Storage Device Detetcion
Next: Volume Shadow Copy Service Restore Operation