Can't disable NTFS last access time updates

Question

Can't disable NTFS last access time updates

Lex Mercatoria 0

I'm running Windows 10 IoT Enterprise LTSC 21H2.

I've tried disabling last access time updates using both these commands:

fsutil behavior set disablelastaccess 1

fsutil behavior set disablelastaccess 3

After issuing each command, I rebooted and tested its effects by updating a test file as follows:

echo "x" 1>> test.txt

For both commands the file's "Date accessed" field in Explorer immediately updates.

Pursuant to Microsoft's File System Algorithms document:

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/4e3695bd-7574-4f24-a223-b4679c065b63

I created a new DWORD value NtfsLastAccessUpdatePolicyVolumeSizeThreshold in the same registry key where NtfsDisableLastAccessUpdate is to test that second fsutil command above so as to make the NTFS driver not update last access times on my 120 GB system drive; by default updates are enable if said drive's capacity <= that registry value's data.

I set the data to 0x1000 (4096 GB), with updates occurring as expected upon reboot. Then I set the value to 0x10 (16 GB), rebooted, and updated the text file. Unfortunately, the "Date accessed" time stamp updates though it should not.

Perhaps people have had success disabling last access time updates with other versions of Windows 10, but I can only conclude this cannot be disabled in this Windows edition except by group policy. The system's local group policy store doesn't have this setting, so I'd have to join the computer to a domain.

My question is this: is this a bug or is this version of Windows 10 written to operate this way?

It would be ridiculous if this is deliberate, as this functionality worked fine in Windows 7.

0 comments

1 answer

Your answer

Answer 1

Hello @Lex Mercatoria

I don't think the behavior you've observed is enough to conclude that Windows 10 IoT Enterprise LTSC 21H2 ignores NtfsDisableLastAccessUpdate or requires Group Policy.

There are two separate things involved here: the mode selected by fsutil and the way NTFS actually maintains the Last Access Time.

First, I would check the effective configuration rather than relying on the registry value alone:

fsutil behavior query disablelastaccess

Microsoft documents four possible states:

0 = User Managed, Last Access Updates Enabled

1 = User Managed, Last Access Updates Disabled

2 = System Managed, Last Access Updates Enabled

3 = System Managed, Last Access Updates Disabled

So:

fsutil behavior set disablelastaccess 1

requests User Managed, disabled, while:

fsutil behavior set disablelastaccess 3

requests System Managed, disabled.

Microsoft's current fsutil behavior documentation describes these modes and also notes that changes to disablelastaccess require a restart before they take effect.

The test itself is important

This command:

echo "x" >> test.txt

doesn't perform only a file access/read operation. It opens and modifies the file.

That means several NTFS timestamps can legitimately change as part of the write operation. Testing the Explorer Date accessed column immediately after modifying the file can therefore be misleading when you're specifically trying to determine whether ordinary last-access tracking has been disabled.

I would use PowerShell to inspect all of the timestamps before and after a read-only operation instead.

For example:

$f = Get-Item C:\Temp\test.txt

$f | Select-Object Name, CreationTime, LastWriteTime, LastAccessTime

Get-Content C:\Temp\test.txt | Out-Null

$f = Get-Item C:\Temp\test.txt

$f | Select-Object Name, CreationTime, LastWriteTime, LastAccessTime

Also bear in mind that NTFS doesn't necessarily update Last Access Time synchronously for every access. Microsoft's file-system specification describes last-access processing as delayed/lazy behavior rather than something applications should expect to be written immediately after every access.

About NtfsLastAccessUpdatePolicyVolumeSizeThreshold

I would be careful about using that registry value as evidence that the documented fsutil setting isn't working.

The Open Specifications document you've referenced describes Windows file-system algorithms and implementation behavior, but those details aren't necessarily intended to be administered by manually creating undocumented/internal registry values.

For a supported configuration test, I'd remove the manually created:

NtfsLastAccessUpdatePolicyVolumeSizeThreshold

value and test using the documented fsutil interface alone.

Start with:

fsutil behavior set disablelastaccess 1

Restart Windows, then verify:

fsutil behavior query disablelastaccess

You should see the equivalent of:

DisableLastAccess = 1 (User Managed, Disabled)

Then perform a read-only test, rather than modifying the file.

One more useful test

You can bypass Explorer entirely:

(Get-Item C:\Temp\test.txt).LastAccessTimeUtc

Record that value, wait, read the file:

Get-Content C:\Temp\test.txt | Out-Null

and check it again:

(Get-Item C:\Temp\test.txt).LastAccessTimeUtc

Using LastAccessTimeUtc also removes local-time/display formatting from the comparison.

If fsutil behavior query disablelastaccess reports:

User Managed, Disabled

after the reboot, but a read-only operation consistently causes the on-disk NTFS $STANDARD_INFORMATION Last Access timestamp to advance, then I think you would have a much stronger case for an OS-specific problem worth investigating.

But I wouldn't use Explorer plus:

echo "x" >> test.txt

as the deciding test, because you're changing the file while trying to isolate its access-time behavior.

If you can post the exact output of: fsutil behavior query disablelastaccess

after setting it to 1 and rebooting, that would be the most useful next data point. It tells us whether Windows actually accepted User Managed / Last Access Updates Disabled, rather than inferring the effective state from Explorer's timestamp display.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.