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. :-)
--
Mike