Thanks for the explanation, that confused me too.
Funny that it is displayed differently on brink system.
Can anybody confirm this?Brink said:
Does this then apply to all other partitions (also possible larger ones) or does it only refer to the C: drive and all others are independent (activated by default?)?
Thanks and greetings,
Martin
I am not sure, the problem is the query command cannot be used with a drive letter, its a global query which would indicate its a global setting, but as you said the system managed is supposed to enable or disable based on the size of the partition.
I have understood the meaning of the descriptions now though, I think Microsoft worded it badly.
So right now I have it set to 1 manually.
As per the syntax help for the set command the 1 value forces timestamps to not be updated on access.
The query command reports this.
DisableLastAccess = 1 (User Managed, Enabled)
The enabled refers to the DisableLastAccess flag, not that timestamps are enabled.
The only way to really confirm if its a per partition setting, is to set system managed (I think 2 or 3 doesnt matter on boot up it will decide what it wants to do), and then open a file on each drive, check the access timestamp after to see if its updated.
You don't need to go that far, just open a folder with lots of files, hold Pg Down and see Explorer freeze up on an intel i9. The corporate retards who thought up this setting decided to update timestamps on every file as you scroll.
If you're copying files from a dying external drive on Windows 10, make DAMN SURE it's mounted read only.
Edit: BTW, I've set it up to run the fsutil command to set the setting to 1 on computer startup. I hope that will stick forever. Never had this issue on Windows 7 >
@Elehpant
Thank you for your feedback!
I can now also confirm that it is a system-wide setting, with Win10 v2004 the 128GB threshold was removed and that the behaviour of this timestamp is so unreliable and partly arbitrary, that I can't imagine it being useful.
No idea why it was activated (again) by Microsoft.
If someone believes in "conspiracy theories", some could almost come to the conclusion that Windows has been artificially slowed down in recent years.
But according to Hanlon's razor, it's probably just pure stupidity in the form of internal chaos and other priorities like "cloud first".
A quick look down the rabbit hole made me realize, that I will be taking timestamps with a grain of salt in the future.
It's amazing and frightening how complicated such a seemingly simple thing can be.
A few pages I stumbled across:
Is there any reason to keep the (new) default of LastAccessTime being updated? (superuser.com)
The (in)consistency of last access timestamps (dfir.ru)
NTFS Timestamps (kazamiya.net)
Do you MFT? Here's an MFT Overview. (community.netwitness.com)
$STANDARD_INFORMATION vs. $FILE_NAME (dfir.ru)
Time for Truth: Forensic Analysis of NTFS Timestamps (PDF)
Using the object ID index as an investigative approach for NTFS file systems (sciencedirect.com)
Quote