Encase 7 Index Buffer Reader script **RECOVERED ENTRY***

Windows 10 does not automatically create a second MS-DOS “compatible”
short (8.3) filename $FN attribute when a file is renamed. It is assumed this is
for efficiency reasons.

There is a per-volume flag to control this behavior. My Windows 10 system writes short names in the system volume. On other volumes, this behavior (along with the tunneling cache) can be disabled.

@thefuf - My impression has always been that the $FN timestamps (in $MFT) were redundant and were not reported by the standard Windows API or applications. I set up a quick experiment to verify what you said about FindFindEx(). Please find results below.

Test procedure

Results

1. Windows Explorer reports $SI timestamps

2. Command prompt DIR command reports $SI timestamps

3. I wrote a quick program to report timestamps via FindFirstFileEx(). The code was

4. When run, this code reported the $SI timestamps (as expected)

5. I then looked at the on disk data using XWF. The MFT entry clearly shows that the $SI timestamps have been modified but the $FN timestamps are those of original creation

6. Finally, I checked the root directory $I30 INDX. Again, this shows the unmodified $FN timestamps

[NOTE This screenshot is wrong - see below]

Conclusions

www.binarymarkup.com

1. Standard Windows APIs report the $SI timestamps
2. The SetFileTime() API modifies the $SI timestamps
3. The $FN timestamps are not reported in Windows Explorer (probably uses FindFirstFile/Ex)
4. The $FN timestamps are not reported by command prompt / DIR (probably uses FindFirstFile/Ex)
5. FindFirstFile/Ex reports the $SI timestamps
6. For most purposes The $FN timestamps are redundant. They reflect the state of $SI timestamp at the point the $FN record was last updated.

Based on the above experiment, I am sorry, but I think your results were incorrect.

With the following exception you were looking at $FILE_NAME timestamps for the "System Volume Information" directory. lol

@thefuf - I am sorry, you are correct. My picture (6) was incorrect.

The $FN timestamps in the INDX are different to the $FN timestamps in the $MFT. I will repeat my experiments. oops

Jim

www.binarymarkup.com

For sure, I can post a sample $MFT file, if anyone wants to see what's happening. The $FILE_NAME timestamps in the index entry are kept in sync with the $STANDARD_INFORMATION timestamps, with the only exception for the last access timestamp (which is likely caused by a bug, not by a feature).

@JimC conducted a test, but he/she provided the $FILE_NAME timestamps from an index entry for another directory, not for a file in question (the timestamps are stored before the name, not after).

Edit less offensive.

I got the following comment from a member of the NTFS development team on why there are timestamps in both $SI and $FN. This may be useful (paragraphs added by me to improve readability)

"I can only speculate but my guess is that very early on in development, the intention was when updating duplicated information in the parent directory that we would first update the $FILE_NAME attribute and then copy that verbatim to the parent directory. That way they would always be exactly in sync. You could look at the $FILE_NAME attributes and know exactly what the duplicated information should look like.

I can tell you (since I have access to all historic released code) that it was already this way in Windows NT 3.1. So if they changed their mind for perf reasons as I suspect, it was done before the initial release. They may have not wanted / had time to do the work of removing those fields from the $FILE_NAME attribute, or they may have just like the symmetry of having $FILE_NAME attributes and duplicated information use the same data structure. But it is a complete waste of file record space that we are still living with. Theoretically if we ever get a chance to make sweeping breaking changes to the on-disk format then we could consider optimizing this."

Jim

www.binarymarkup.com

I got the following comment from a member of the NTFS development team on why there are timestamps in both $SI and $FN. This may be useful (paragraphs added by me to improve readability)

"I can only speculate but my guess is that very early on in development, the intention was when updating duplicated information in the parent directory that we would first update the $FILE_NAME attribute and then copy that verbatim to the parent directory. That way they would always be exactly in sync. You could look at the $FILE_NAME attributes and know exactly what the duplicated information should look like.

Importantly if a directory got corrupted and needed to be re-created from scratch by chkdsk, it would end up getting created with the precise duplicated information it would have had. But I'm guessing the early developers quickly realized the perf impact of having to update the $FILE_NAME attribute every time duplicated information got updated, including logging the update of the $FILE_NAME attribute, was just not worth it just to maintain that property. So they ended up just leaving the $FILE_NAME attribute alone, except as you noticed when the $FILE_NAME attribute needs to be updated anyway for a name change, the duplicated fields can get updated at that time because it is basically free.

I can tell you (since I have access to all historic released code) that it was already this way in Windows NT 3.1. So if they changed their mind for perf reasons as I suspect, it was done before the initial release. They may have not wanted / had time to do the work of removing those fields from the $FILE_NAME attribute, or they may have just like the symmetry of having $FILE_NAME attributes and duplicated information use the same data structure. But it is a complete waste of file record space that we are still living with. Theoretically if we ever get a chance to make sweeping breaking changes to the on-disk format then we could consider optimizing this."

Jim

www.binarymarkup.com

The only thing I can add is that there is a need to keep $FILE_NAME timestamps (and other $FILE_NAME metadata) in a directory index this allows a program to retrieve more information about a file with a single system call. I'm happy that NTFS developers didn't do that in the Linux way (a system call to get a next file name and inode information, then another system call for metadata about that inode).

I tried another experiment to get to the bottom of this once and for all. This time I used XWF to manually edit the 3 different sets of time stamps to each have a unique value (changed the year in each) giving 12 unique values. The 3 timestamp locations were

1. MFT / $SI
2. MFT / $FN
3. INDX / $FN

I then checked again with Windows Explorer, FindFirstFileEx etc. The results were

1. FindFirstFile/Ex (and applications) report the INDX timestamps
2. The MFT / $FN timestamps are not reported
3. Changes to timestamps by SetFileTime() are reflected in $SI and INDX / $FN

My apologies to @thefuf. He was correct.

The mistake I made was to assume the timestamps in the INDX were identical to that in the MFT / $FN. I made this mistake because the storage structure is very similar (but not quite identical). This isn't the case - it looks like the NTFS developers reused the same structure but don't keep the timestamps in sync. As per my last post, the timestamps in MFT / $FN seem to only be updated when that attribute is re-written (when they come from $SI).

Jim

www.binarymarkup.com