NTSF MFT Entry Modified

Indeed. This is why I said they were "apparently" redundant.

I think that the Microsoft developer told me that he thought the timestamps in $FILE_NAME were a left over from an early optimization that was dropped before NTFS was first publicly released. The same structure is, of course, present in the directory indexes which is possibly why they remain to this day. My original experiment didn't address this. I haven't tried it yet but I expect the index timestamps are updated in sync with the $STANDARD_INFORMATION.

Jim

www.binarymarkup.com

I haven't tried it yet but I expect the index timestamps are updated in sync with the $STANDARD_INFORMATION.

There are many real-world situations when these timestamps are out-of-sync (and I saw one with a keylogger's journal having different timestamps in these two sources). Even the official documentation states that they can be out-of sync:

Note  In rare cases or on a heavily loaded system, file attribute information on NTFS file systems may not be current at the time this function is called. To be assured of getting the current NTFS file system file attributes, call the GetFileInformationByHandle function.

the timestamps in $FILE_NAME were a left over from an early optimization that was dropped before NTFS was first publicly released

There are many real-world situations when these timestamps are out-of-sync (and I saw one with a keylogger's journal having different timestamps in these two sources). Even the official documentation states that they can be out-of sync:

Note  In rare cases or on a heavily loaded system, file attribute information on NTFS file systems may not be current at the time this function is called. To be assured of getting the current NTFS file system file attributes, call the GetFileInformationByHandle function.

I think you should have included exactly where that caveat appears.  I find it in the documentation of FindNextFile(), which seems likely to be used by software that enumerates files in directories, such as software for creating live images or file archives. 

Microsoft documentation also says somewhere that the only situation in which on-disk file time stamps are guaranteed to be 'correct' is when the file has been closed for access (this flushes all in-core data related to that file/file handle to disk). That is, a live image (done through the use of FindNextFile() and related calls) cannot be guaranteed to be 'true', and must be interpreted with this in mind, unless additional precautions are taken.  The same will obviously be true for unclean file systems, where normal closing and dismounting has not been done, perhaps due to a crash or a hard power failure.

Additionally, there is (or was) a documented limit to such out-of-sync-ness: at most one hour before an in-core time stamp was synced with on-disk structures.  This is almost certainly a worst-case situation: in most situation it happens must faster. But in situations where a file has been opened for processing, and processing stalls for any reason (bug, lack of input data, etc.), the latest time stamps (typically last access, if enabled, and probably also the modification timestamps) might remain un-flushed until some internal NTFS book-keeping flushing done on a one-hour basis is performed. 

This means that any NTFS time stamp taken from a live image might, in the worst case, be out of sync by at most one hour. If proper precautions are taken by the imaging software, that may be reduced to minimal amounts. Whether or not proper precautions are taken for closed-source software needs the support of the manufacturer of that software to clarify, or some serious testing on heavily loaded systems.

I think you should have included exactly where that caveat appears.

See my blog post (linked above) for at least one related condition.

Microsoft documentation also says somewhere that the only situation in which on-disk file time stamps are guaranteed to be 'correct' is when the file has been closed for access (this flushes all in-core data related to that file/file handle to disk).

Not really. The NTFS driver attempts to provide consistent & up-to-date metadata when an application tries to read from a logical volume (e.g., \\.\C:) directly. Thus, simply reading from a logical drive (e.g., using FTK Imager Lite) can change many timestamps ("older" timestamps will be replaced by "newer" ones).

Additionally, there is (or was) a documented limit to such out-of-sync-ness: at most one hour before an in-core time stamp was synced with on-disk structures.

[...]

This means that any NTFS time stamp taken from a live image might, in the worst case, be out of sync by at most one hour. If proper precautions are taken by the imaging software, that may be reduced to minimal amounts.

Not true. There was a documented limit for the last access timestamp updates, but it wasn't enforced (in fact, the documentation is slightly wrong). I have seen last access timestamps not being updated for more than 12 hours (no shutdown/sleep/hibernation involved). Again, this was documented long time ago.

Also, how about 22 hours for the file modification timestamp? I have seen that on a real system. (Other examples in the blog post linked before.)

@jimc

These links may be relevant to the OP's needs, and to your interests:

http://www.kazamiya.net/en/NTFS_Timestamps

https://www.sciencedirect.com/science/article/pii/S1742287619300234