Alex Ionescu wrote:
Windows uses the FILE_READ_DATA flag here, not FILE_READ_ATTRIBUTES.
Yes? And?
Let's study the code and the open modes used here.
This code tries to open Device\HarddiskN\Partition0 (N = 0 ...) for the sole purpose of checking for availability, and immediately close the handle if the open succeeded.
Why would one use FILE_READ_DATA if one never intended to read anything?
The code also uses SYNCHRONIZE. Why would one use SYNCHRONIZE if one never intended to wait on the handle?
As I see it, that's just requesting extra work for the purpose of nothing.
The purpose of that open call is only to see if the disk exists, and if so create the symbolic link PhysicalDriveN -> HarddiskN\Partition0.
I don't buy "Windows does this" without backing it up with any arguments whatsoever as to why Windows does this. Perhaps Windows does more with the returned handle than immediately closing it, something that actually requires READ_DATA?
all this is doing is hiding the bug (which is somewhere in vfat)
I'm looking forward to the explanation of how opening HarddiskN\Partition0 (not "Partition1", not "Partition1", but "Partition0" - aka the whole disk) would involve any filesystem activity whatsoever?
Because it's now gone, it'll probably happen in some mysterious application 2 years from now and nobody will know why.
Hahaha, you really are a joker. An app? Calling xHalIoAssignDriveLetters, that is called with a frickin' LoaderBlock?
That function is used exactly once, during system startup.
Health reasons suggest not holding your breath while waiting for such an application. :-)