fs_handle::parent_path_handle() always fails on ReFS/DevDrive

[BurningEnlightenment]

llfio/include/llfio/v2.0/detail/impl/windows/fs_handle.ipp

Lines 111 to 119 in 418a2e9

	FILE_INTERNAL_INFORMATION fii{};
	ntstat = NtQueryInformationFile(nh, &isb, &fii, sizeof(fii), FileInternalInformation);
	if(STATUS_SUCCESS != ntstat)
	{
	continue;
	}
	// If the same, we know for a fact that this is the correct containing dir for now at least
	// FIXME: We are not comparing device number, that's faked as the volume number in stat_t
	if(static_cast<ino_t>(fii.IndexNumber.QuadPart) == _inode)

On a ReFS/DevDrive this check consistently fails, i.e. fii.IndexNumber.QuadPart != _inode as the actual value is fii.IndexNumber.QuadPart == _inode | 0x5000'0000'0000'0000. I haven't yet checked how this syscall differs from the one retrieving _inode.

Windows specifications:

Edition		Windows 11 Enterprise
Version		22H2
OS build	22621.3007
Experience	Windows Feature Experience Pack 1000.22681.1000.0

[ned14]

This used to work on ReFS, but it hasn't been tested in a long, long time. And Windows may have changed what it publishes.

I can certainly see here it would. ReFS if I remember rightly uses 128 bit inodes, and LARGE_INTEGER is 64 bit. It used to return the bottom or top 64 bits, and LLFIO generally just worked on ReFS as a result. I can see them maybe ORing some constant, or maybe some other change got in there. Who knows.

What ought to be done is figure out what the new Windows API which returns 128 bit inodes is, and use that when available. I think fs_handle's inode type is 128 bit, so it's good to go.

Or, we could be lazy, and just OR in those bits during the comparison :)