You might already know that the NTFS “Last Access” updates will be back by default in Windows 10 “20H1”. Previously, there were back for installations with small system volumes only. What is the reason behind this? Why do we need last access timestamps?
If you visit the “Configure Storage Sense or run it now” page in the “Settings” window of Windows 10 “19H2”, you may notice the “Delete files in my Downloads folder if they have been there for over” option. The same option in “20H1” reads: “Delete files in my Downloads folder if they haven’t been opened for more than“.
So, this old new NTFS feature has something to do with Storage Sense. It’s a component used to delete unneeded files “to keep your storage optimized”. And the “Last Access” updates are a good way to detect such unneeded files (and the “StorageUsage.dll” library actually uses last access timestamps to find “cold” files).
But there is something you might not notice. Look at the same settings page in Windows 10 “19H2” and read:
"OneDrive Content will become online-only if not opened for more than"
Wait a minute! The “Last Access” updates are on for a relatively small subset of Windows 10 “19H2” installations only… Does this option really work for systems with large system volumes?
Let’s install the Windows 10 “19H2” operating system to a 500 GiB virtual hard disk drive, log in using an online account, and enable various OneDrive features. After the installation, the “fsutil behavior query disablelastaccess” command returns 3 (it means that the “Last Access” updates are disabled). The “NtfsDisableLastAccessUpdate” registry value is 0x80000003 (it means the same).
Now let’s create two text files on the desktop and write some data to one of them (in my setup, these files are marked with a green tick icon, which means “a locally available file”):
After this, I wait for more than an hour and then record the $STANDARD_INFORMATION timestamps of these files (the files are actually stored under the OneDrive directory):
- lll.txt
- Created: 2020-05-21 22:12:33.419851400 (MSK)
- File Modified: 2020-05-21 22:02:21.827205700 (MSK)
- MFT Modified: 2020-05-21 22:02:30.967656500 (MSK)
- Accessed: 2020-05-21 22:02:21.827205700 (MSK)
- ppp.txt
- Created: 2020-05-21 22:13:12.919944700 (MSK)
- File Modified: 2020-05-21 22:02:39.764888700 (MSK)
- MFT Modified: 2020-05-21 22:02:51.124157600 (MSK)
- Accessed: 2020-05-21 22:02:39.764888700 (MSK)
Now, I will open both files (by double-clicking on them, a Notepad window is then shown), power off the system (to flush all modified data to the drive), then check the timestamps again, and… Nothing happens!
I boot the system again, open the files… Still, no change to timestamps (this time I do the check without turning the system off). Then, I go to the settings, turn Storage Sense on, and try again… No changes after the files have been opened one more time. Finally, I set the online-only threshold to 14 days, and… The timestamps are updated after the files are opened once more!
- lll.txt
- Created: 2020-05-21 22:12:33.419851400 (MSK)
- File Modified: 2020-05-21 22:02:21.827205700 (MSK)
- MFT Modified: 2020-05-21 23:14:02.583202100 (MSK)
- Accessed: 2020-05-21 23:14:02.583202100 (MSK)
- ppp.txt
- Created: 2020-05-21 22:13:12.919944700 (MSK)
- File Modified: 2020-05-21 22:02:39.764888700 (MSK)
- MFT Modified: 2020-05-21 23:13:57.380122800 (MSK)
- Accessed: 2020-05-21 23:13:57.380122800 (MSK)
But the “fsutil behavior query disablelastaccess” command returns 3. So, the “Last Access” updates are still disabled in the NTFS driver!
I power off the system and wait for multiple hours. After the boot, I open one of those files (“lll.txt”) again, immediately power off the system, and see that the timestamps are the same (unchanged)…
Then, I repeat the previous test, but open the same file multiple times (and view its properties in between). After shutting the system down, I check timestamps of the file and see them updated:
- lll.txt
- Created: 2020-05-21 22:12:33.419851400 (MSK)
- File Modified: 2020-05-21 22:02:21.827205700 (MSK)
- MFT Modified: 2020-05-22 08:37:37.872784600 (MSK)
- Accessed: 2020-05-22 08:37:37.872784600 (MSK)
(Timestamps of another file are the same as before.)
I boot the system again and check the output of the “fsutil behavior query disablelastaccess” command, it’s the same (3). Then, I delete the “lll.txt” file and focus on the “ppp.txt” file. I open this file and wait… Its last access timestamp is the same. I open that file multiple times (and view its properties in between)… And the “MFT Modified” and “Accessed” timestamps are updated! (The “fsutil behavior query disablelastaccess” command still prints 3, just as before.)
- ppp.txt
- Created: 2020-05-21 22:13:12.919944700 (MSK)
- File Modified: 2020-05-21 22:02:39.764888700 (MSK)
- MFT Modified: 2020-05-22 08:52:11.797791500 (MSK)
- Accessed: 2020-05-22 08:52:11.797791500 (MSK)
Now, I turn off the online-only threshold (by changing it to “Never”) and wait for one hour. Then, I open the “ppp.txt” file two times (and view the properties of this file in between and after). The timestamps are updated in a similar way again! (The “fsutil behavior query disablelastaccess” command still returns 3.)
It appears that first attempts to test the behavior were inconclusive. Not all actions trigger an update of the last access timestamp.
Now, let’s do a fresh install of the same operating system using the same configuration, but keep Storage Sense off to see what happens when “a cloud-backed file” is opened. A new file (“rrr.txt”) is created by me, filled with some data, and the system is then powered off for one hour.
Before the boot, the following timestamps are observed:
- rrr.txt
- Created: 2020-05-22 13:32:48.492335800 (MSK)
- File Modified: 2020-05-22 13:32:55.336092300 (MSK)
- MFT Modified: 2020-05-22 13:35:39.587939600 (MSK)
- Accessed: 2020-05-22 13:32:55.336092300 (MSK)
After the boot, the “Last Access” updates are reported as disabled (by the fsutil program). After opening the file multiple times (and viewing its properties in between), the timestamps are updated:
- rrr.txt
- Created: 2020-05-22 13:32:48.492335800 (MSK)
- File Modified: 2020-05-22 13:32:55.336092300 (MSK)
- MFT Modified: 2020-05-22 14:59:16.649969300 (MSK)
- Accessed: 2020-05-22 14:59:16.649969300 (MSK)
I move the system clock one day forward, do the same, and see similar updates.
So, the “Last Access” updates happen when files are read even if Storage Sense is disabled (again, first attempts documented in this post were inconclusive) and the NTFS driver is configured not to do such updates. These timestamps aren’t updated every time a text file is opened in the Notepad application, but they are updated at some point (with no other action except viewing a file or its properties performed)! The only limitation is that these files should be managed by the OneDrive client.
The key to solve this problem is found in the “cldflt.sys” driver. This is a filter driver used by the OneDrive client, it’s responsible for intercepting I/O requests, so they could be served as usual ones but with cloud in mind (for example, when file content isn’t available locally).
One of its callback functions named “HsmFltPreREAD” includes a reference to a function named “HsmpUpdateLastAccessTime”. The latter updates the last access timestamp of a file being read (using the FltSetInformationFile() routine) if current time is at least one hour ahead of the current timestamp value.
The conclusion is: the “Last Access” updates for files belonging to the OneDrive cloud are managed by its filter driver, not by the NTFS driver. These updates happen even if the NTFS driver is configured not to update the last access timestamp on a file read event.
So, the “Last Access” updates were back for such files before the release of Windows 10 “20H1”.
And one unanswered question: why opening a file with Notepad doesn’t always trigger an update to the last access timestamp?
Update (2020-06-04): this behavior can be traced back to Windows 10 “Redstone 3” (1709).
My DFIR Blog 