FILE_BASIC_INFORMATION::LastAccessTime.QuadPart can be -2

Documented Behavior:
If you set FILE_BASIC_INFORMATION::LastAccessTime to 0xFFFFFFFF’FFFFFFFF (-1) and call NtSetInformationFile(FileBasicInformation), the subsequent write (on the same handle) operation doesn’t update LastWriteTime.

Undocumented Behavior:
If you set FILE_BASIC_INFORMATION::LastAccessTime to 0xFFFFFFFF’FFFFFFFE (-2) and call NtSetInformationFile(FileBasicInformation), this cancels the effect of disabling LastWriteTime update on write I/O.

Works on Windows 10 build 170928 (haven’t checked any earlier builds). ExFat and FastFat don’t care and return STATUS_INVALID_PARAMETER. Used by the Could File System minifilter (Cldfs.sys) with OneDrive files.

Ladislav, Thanks for this. Its great to have visibility into these changes
and this forum is a great way of finding out before we suddenly discover
that windows update has started to fail because of some undocumented change
in semantics.

Do I read it correctly that “Obvious implementation” is that there is now a
flag in the Scb? Do we know whether the setting is persistent, and if so
whether there is a way of knowing whether it has been set?

Rod

> Do I read it correctly that “Obvious implementation” is that there is now a

flag in the Scb?

From what I saw in NTFS code, there is a flag in the CCB; this flag
is now cleared when the value of -2 in FILE_BASIC_INFO::XxxTime
is encountered.

Do we know whether the setting is persistent, and if so
whether there is a way of knowing whether it has been set?

As far as I know, the setting only applies to that single handle,
the same way like it’s documented with XxxTime = -1.

L.

> From what I saw in NTFS code, there is a flag in the CCB; this flag

is now cleared when the value of -2 in FILE_BASIC_INFO::XxxTime
is encountered.

Gotcha, Its an undo, like the “Undo Delete on close” thing… I just
didn’t parse your text correctly first time (which is shaming given that it
was clear and English is my first language).

Thanks again.

Is it worth putting in a change not for the documentation? It looks as
though the documentation writers are pretty responsive (call me sad, I
monitor the raw commit stream to github).

R

Just to FU here. Someone threw a request into github (https://github.com/MicrosoftDocs/windows-driver-docs-ddi/issues/318) and the writers there haven’t been able to find out anything about this setting.

So I’m following what @Ladislav_Zezula says until someone in MS cna come up with a definitive statement

Interesting that even Microsoft people can’t find an answer. Perhaps I shall write a small testprogram to demonstrate that behavior :slight_smile:

It will be documented, it’s in the queue. The behavior has been there since Blue S14.

Please bear with us as we try to bring the documentation up to date with the limited resources we have. It’s not out of malice! We appreciate all reports of inaccuracies or omissions.

Those of us, who remember the documentation in the first 10 years (i.e. “what documentaton”) appreciate the work.

Since I can submit direct feedback in IE, I do that now :slight_smile: I see that even suggestions related to actual funcitonality get through, of course only after checking that the info is correct, with other MS staff.

Documented:
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/ns-wdm-_file_basic_information

Thanks!

Yea, thanks go to @LoriWhipplerHollasch and @Craig_Barkhouse for their Augean work in bringing this stuff up to date…