±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35868
New Yesterday: 0 Visitors: 146

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

More Windows date and time fun! -- another take

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
 
  

athulin
Senior Member
 

More Windows date and time fun! -- another take

Post Posted: May 22, 15 10:17

In a separate thread titled 'More Windows date and time fun!' the semantics of the registry setting NtfsDisableLastAccessUpdate = 1 is being discussed, particularly as it is being traced back to NT 4.00

It struck me that it might be useful to discuss how to design a test to verify the behaviour of this setting.

There's one claim that it only affects directory time stamps -- so one part of the test needs to access something like C:/A/B/C/D/E/F/TEST.DAT, and check which Last Access timestamps of directories and the TEST.DAT file were updated for different settings of the registry.

There must be some effort to isolate the test directories or files -- nothing else must access those resources during the test. Or perhaps the test should be performed multiple times to at least detect any differences in behaviour.

File system must be dismounted after the test to ensure all and any write caches are flushed properly.

At least one test should be done with Windows API calls only. There may be value in performing another test using Windows Shell, as it is known to implement its own time stamp rules in some use cases (known cases involve file move and copy across file systems). And it may be useful to repeat tests in DOS and PowerShell shells ex abundanti cautelae.

And just to be perverse, it may be an idea to perform the programmatic test for Win32 as well as POSIX.

Other ideas?  
 

Page 1 of 1