Any idea how a file might end up with a reparse tag of 0x0006008A?

[FeralSquid]

Hello,

Several people are now using my solution that uses ProjFS successfully ... but so far I have one user that has ended up with a handful of their ProjFS files with a reparse tag of 0x0006008A ... that isn't one of the two ProjFS tags I know of (0x9000001C, 0xA0000022).

It doesn't have the Microsoft high bit set ... and it has non-zero values in its "reserved" range, so seems like it might even be bogus / an error?

My google searches haven't turned anything up yet that claims it...

Any ideas?

[cgallred]

Sorry, doesn't look familiar to me. Like you guessed, that isn't a valid reparse tag:

//
// The following constant represents the bits that are valid to use in reparse tags.
//

#define IO_REPARSE_TAG_VALID_VALUES     (0xF000FFFF)

So the OS would reject it as a reparse tag since it falls afoul of IO_REPARSE_TAG_VALID_VALUES.

[FeralSquid]

ok, I just had basically the same thing happen to another user. This user had ~50 files with 0x621 file attributes (reparse point, readonly, sparse, archive) with a reserved0 of 0x0006016E or 0x0006008A (like last time).

These filesystem items where at the path of virtual files. Attempting to read the file converted them into a hydrated placeholder.

Turns out this user had some corrupt files and had recently run chksdk (which reported repairing things, I don't have logs) ... perhaps this is something that can happen as a result of chkdsk?

[cgallred]

These filesystem items where at the path of virtual files. Attempting to read the file converted them into a hydrated placeholder.

If I understand correctly, are you saying that this user had files where:

• WIN32_FIND_DATA.dwFileAttributes had 0x400 (FILE_ATTRIBUTE_REPARSE_POINT) set
• WIN32_FIND_DATA.dwReserved0 had 0x0006016E or 0x0006008A instead of a ProjFS reparse point
• But reading the files worked anyway, turning them into hydrated placeholders?

[FeralSquid]

Correct ... based on your response it sounds like this is unexpected / didn't ring any bells, so I poked some more at one of these files.

• FindFirstFileEx(FINDEX_ADDITIONAL_FLAGS.FIND_FIRST_EX_ON_DISK_ENTRIES_ONLY) reports the flags and Reserved0 mentioned previously (I believe this file reported 0x0006008A)
• DeviceIoControl(FSCTL_GET_REPARSE_POINT), though, returns a valid looking ProjFS reparsepoint data structure

Oddly, then, the next time I ran these commands (after adjusting my script to display something as hex, etc), the file was "fixed". Its Reserved0 was 0x9000001C, it reports as a hydrated placeholder and its file data looks correct.

Nothing else should have been touching this file ... so it seems like the DeviceIoControl() call reset the Reserved0 or something? I had done many FindFirstFileEx() calls with no change before adding the DeviceIoControl() call.

Even more interesting is that my provider logs don't report a GetFileData() callback occurring for this file today at all ... so would seem to have been hydrated already some time ago, then Reserved0 was messed up by something, and then Reserved0 was restored and it is working normally now.

Perhaps that is why I've seen two distinct but consistent Reserved0 values? One for hydrated and one for not?

Unfortunately, now that that file was unexpectedly "fixed", I have no more files in this bad state to experiment on.

[cgallred]

ProjFS only has two reparse point values:

#define IO_REPARSE_TAG_PROJFS                   (0x9000001CL)
#define IO_REPARSE_TAG_PROJFS_TOMBSTONE         (0xA0000022L)

The hydrated/not-hydrated state for a IO_REPARSE_TAG_PROJFS reparse point is stored in the opaque buffer at REPARSE_DATA_BUFFER.GenericReparseBuffer.DataBuffer. I don't know why FirstFirst/FindNext would report anything but either of those values for a ProjFS reparse point.

These filesystem items were at the path of virtual files.

I'm not 100% clear what that means. That these were inside the virtualization root, or that they should have been virtual (i.e. projected only, no placeholder)? I assume the former, since if it were the latter FindFirstFileEx(FIND_FIRST_EX_ON_DISK_ENTRIES_ONLY) shouldn't have shown them to you at all.

When this condition happens, is there any user-visible effect? Since the files for this last user were still accessible it seems not, but I wanted to be sure.

[FeralSquid]

"These filesystem items were at the path of virtual files." I mean that the paths for these local corrupted filesystem entries were valid paths in the virtual backing store (they weren't local only files or locally modified files), so they should have been placeholders or hydrated placeholders.

As for user impact ... true, given that it seems to have worked itself out automatically, there may not be user visible effects typically.

In my case there were because my process for updating local state when the backing store changes is to iterate all local entries and update them based on their current state (placeholder/full/tombstone, readonly/writable, etc). In this case these weren't classified as placeholders because of their odd Reserved0 value, and so I didn't update them (thinking them to be some other random local thing, like perhaps a junction). This caused an error for the user because some were dlls that had changed (but had been hydrated at a previous version) and so tripped our dll / assembly version checking mechanism in some of our applications.

To workaround this, my code will now remove the local filesystem entry (virtualizationInstance.DeleteFile) for reparse points with Reserved0 values that are invalid for reparse tags if the path exists in the virtual backing store, turning them back into virtual files.

I think that is fine ... but wanted to let you know of this odd situation that we've now seen twice.