25 Oct
2007
25 Oct
'07
7:52 p.m.
Are you blind, my friend?
Have I once said that there is some sort of reason why
FILE_READ_ATTRIBUTES is incorrect? I have not.
What I have said is that this code SHOULD WORK with FILE_READ_DATA
(as it does on Windows). On ReactOS, it does not.
Requesting FILE_READ_DATA in such a scenario may be done by an app.
Such an app would NOT WORK in ReactOS, because vfat has a bug
handling this scenario. Therefore, what you have done is:
1) Hide a bug that we could see at every boot/install, and easily
test a fix for.
2) Delayed the appearance of this bug until an application will use
FILE_READ_DATA under the same conditions as xHalIoAssignDriveLetter.
This has NOTHING to do with wether or not FILE_READ_DATA is needed
instead of FILE_READ_ATTRIBUTES from a technical standpoint -- as far
as I can see, it isn't. It has to do with an ENGINEERING issue. Do we
want to hide this bug? No we don't.
--
Best regards,
Alex Ionescu
On 25-Oct-07, at 2:08 PM, tamlin(a)algonet.se wrote:
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
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev