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. :-)
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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Alex Ionescu -
tamlin＠algonet.se