Strange behavior with FILE_ATTRIBUTE_TEMPORARY on FAT FS (16, 32, Ex)

Hello guys,

I tried to run HLK “File IO 2 Tests” on my minifilter but it failed on Fat FS because the attribute FILE_ATTRIBUTE_TEMPORARY was cleared on the file when the last handle was closed (UDF, REFS and NTFS pass the test).

In my Cleanup Pre/Post operation callback, the FileObject has the flag FO_TEMPORARY_FILE but when I reopen it, the attribute was cleared.

I tried to debug fastfat.sys, from the open to the close, the FCB->FcbState has FCB_STATE_TEMPORARY and the FileObject->Flags has FO_TEMPORARY_FILE.

I don’t understand how/when/why the flag is cleared after the last handle is closed.

It’s possible that the CacheManager clear this bit in specific case ?

And you’ve checked the (hopelessly out of date, but still slightly useful) sources?

From your symtoms, my bet would be that FAT (the on disk structure) has nowhere to store this bit and so FAT (the FSD) stores the value in the FCB so when the F B is vaporized (just after the last close) the bit goes away. Why your filter impacts this is a mystery

Yes I have checked the sources, but can’t find anything related to this attribute.
fastfat just set or clear the attribute but do nothing with it.

Sounds like my hypothesis is correct then (I haven’t looked at the code). For as long as the FCB exists the value is returned, as soon as its gone the attribute is gone. In that case it is strange that the test look for persistence in the FAT case.

The strange fact is that when I run the test without my driver, FAT FS pass the test.
And I don’t use FltSetInformationFile with BasicInfo or another InformationClass with attributes…

So you need to work out what your filter is doing to cause the FCB to be ejected - and if this is the case (A break point on the last close might be instructive).

And if you can definitively prove that the test is in error (which I should emphasise is only a hypothesis right now) you could try to raise this with the test people at Microsoft. I suspect that they no longer lurk in here, but someone else in this list might know how to proceed…

Honestly I don’t think the test is in error.

It’s just that I don’t understand the fast enought at this time ! I will dig your hypothesis.

Thank you again for your time rob.

I found it !

The test is in error, this attribute is not used by the FAT, when you set this attribute, you don’t see the IRP_MJ_CLOSE, only the IRP_MJ_CLEANUP, because CcManager keep the FileObject alive to preserve this attribute.
If you restart Windows or unmount the drive, the file lost this attribute.

I will create another post to contact the test peoples.

Thank you for all rob !