User talk:Craigbarkhouse

NTFS Timestamp behavior
I am investigating the forensic behaviour of NTFS as part of my masters theses. One area that I have been looking at in particular is the timestamps of the $STANDARD_INFORMATION and $FILE_NAME attributes in NTFS. If possible, I would be very grateful for any help you can give me on the following questions:

a. The $FILE_NAME attribute includes the 4 apparently redundant timestamps. Are these present for performance (or other) reasons?

b. These timestamps are initially synchronised with the $STANDARD_INFORMATION timestamps but quickly diverge. Experiments have found they are only updated when the associated filename record is modified (for instance by a rename operation) when they, sometimes curiously, inherit the $STANDARD_INFORMATION timestamps immediately before the operation. Is there a reason for this behaviour?

c. There are some operations where the 4th "Entry modified" timestamp in the $STANDARD_INFORMATION attribute is not modified despite other timestamps being updated. For instance, on a file copy operation the last access timestamp of the source file can be updated (if this feature is enabled) but the Entry modified timestamp remains stubbornly unchanged. Do you think this is an implementation bug or is there a reason for this oddness?

I understand you may not be in a position to confirm this information. Any help would be very appreciated. — Preceding unsigned comment added by Jimclarkuk (talk • contribs) 23:20, 24 November 2016 (UTC)