User talk:Craigbarkhouse

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Hello, Craigbarkhouse, and Welcome to Wikipedia! Thank you for your contributions to this free encyclopedia. If you decide that you need help, check out Getting Help below, ask me on my talk page, or place {{Help me}} on your talk page and ask your question there. Please remember to sign your name on talk pages by using four tildes (~~~~) or by clicking if shown; this will automatically produce your username and the date. Also, please do your best to always fill in the edit summary field with your edits. Below are some useful links to facilitate your involvement. Happy editing! – —EncMstr (talk) 05:27, 15 August 2016 (UTC)[reply]
Getting started
Getting help
Policies and guidelines

The community

Writing articles
Miscellaneous

NTFS Timestamp behavior[edit]

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 (talkcontribs) 23:20, 24 November 2016 (UTC)[reply]