Re: Patch to fix bug 17619 - GetDriveTypeW reporting C: as a network share if /home is an NFS share
On Fri, 6 Mar 2009, Forest Hale wrote:
Fixed GetDriveTypeW to always report C: as DRIVE_FIXED, preventing problems with the Steam installer if /home is a network share or other special mount.
+ if (root && (root[0] == 'C' || root[0] == 'c')) return DRIVE_FIXED;
I think you should not hardcode the c: drive here. Something based on GetSystemDirectory(), GetWindowsDirectory() or one of their relatives would be better (not sure exactly which should be used). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.
I happen to agree with that sentiment, but Wine creates ~/.wine/drive_c and configures it as C:, for the sake of all common users this is correct. To force C: to be a fixed drive is not harmful in any case I can think of. It does not help if you set up wine with an installation in another drive letter, but that is a separate issue. Francois Gouget wrote:
On Fri, 6 Mar 2009, Forest Hale wrote:
Fixed GetDriveTypeW to always report C: as DRIVE_FIXED, preventing problems with the Steam installer if /home is a network share or other special mount.
+ if (root && (root[0] == 'C' || root[0] == 'c')) return DRIVE_FIXED;
I think you should not hardcode the c: drive here. Something based on GetSystemDirectory(), GetWindowsDirectory() or one of their relatives would be better (not sure exactly which should be used).
-- LordHavoc Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces/ Co-designer of Nexuiz - http://alientrap.org/nexuiz "War does not prove who is right, it proves who is left." - Unknown "Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass "A game is a series of interesting choices." - Sid Meier
2009/3/8 Forest Hale <lordhavoc(a)ghdigital.com>:
I happen to agree with that sentiment, but Wine creates ~/.wine/drive_c and configures it as C:, for the sake of all common users this is correct.
To force C: to be a fixed drive is not harmful in any case I can think of.
It does not help if you set up wine with an installation in another drive letter, but that is a separate issue.
Francois Gouget wrote:
On Fri, 6 Mar 2009, Forest Hale wrote:
Fixed GetDriveTypeW to always report C: as DRIVE_FIXED, preventing problems with the Steam installer if /home is a network share or other special mount.
+ if (root && (root[0] == 'C' || root[0] == 'c')) return DRIVE_FIXED;
I think you should not hardcode the c: drive here. Something based on GetSystemDirectory(), GetWindowsDirectory() or one of their relatives would be better (not sure exactly which should be used).
I'm not sure kernel32 is the right place for this test though. I've started a discussion about the same basic idea in mountmgr.sys instead ... There's still a little bit of question on whether forcing C: to DRIVE_FIXED is correct :)
The problem with mountmgr is that it's not even calling the type function because the NtQueryVolumeInformationFile is asking the Linux kernel about this path and the Linux kernel is saying it's in an NFS filesystem on my computer (which is true), then it's reporting it as a network drive, and not even checking with the mountmgr at all. So I overrode it in kernel32 as the most direct workaround for this specific problem. I still get the same problem if I choose to install Steam on any other drive mount that happens to be in an NFS path, but I could not simply make the mountmgr override the NtQueryVolumeInformationFile result because mountmgr is always returning DRIVE_FIXED for drives with no registry key, which is indistinguishable from an intentional override of type (in other words - NtQueryVolumeInformationFile would be entirely ignored, and I assume it was intentional that it reported a network share in this case). The Steam installer refuses to install on anything other than DRIVE_FIXED (probably because it's simply not designed for roaming of any sort, and wants to keep users from doing something that won't work). So without getting into the details, I simply made C: always work properly (at least with any automatic wine install I can imagine). Ben Klein wrote:
2009/3/8 Forest Hale <lordhavoc(a)ghdigital.com>:
I happen to agree with that sentiment, but Wine creates ~/.wine/drive_c and configures it as C:, for the sake of all common users this is correct.
To force C: to be a fixed drive is not harmful in any case I can think of.
It does not help if you set up wine with an installation in another drive letter, but that is a separate issue.
Francois Gouget wrote:
On Fri, 6 Mar 2009, Forest Hale wrote:
Fixed GetDriveTypeW to always report C: as DRIVE_FIXED, preventing problems with the Steam installer if /home is a network share or other special mount.
+ if (root && (root[0] == 'C' || root[0] == 'c')) return DRIVE_FIXED; I think you should not hardcode the c: drive here. Something based on GetSystemDirectory(), GetWindowsDirectory() or one of their relatives would be better (not sure exactly which should be used).
I'm not sure kernel32 is the right place for this test though. I've started a discussion about the same basic idea in mountmgr.sys instead ... There's still a little bit of question on whether forcing C: to DRIVE_FIXED is correct :)
-- LordHavoc Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces/ Co-designer of Nexuiz - http://alientrap.org/nexuiz "War does not prove who is right, it proves who is left." - Unknown "Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass "A game is a series of interesting choices." - Sid Meier
2009/3/8 Forest Hale <lordhavoc(a)ghdigital.com>:
The problem with mountmgr is that it's not even calling the type function because the NtQueryVolumeInformationFile is asking the Linux kernel about this path and the Linux kernel is saying it's in an NFS filesystem on my computer (which is true), then it's reporting it as a network drive, and not even checking with the mountmgr at all.
So I overrode it in kernel32 as the most direct workaround for this specific problem.
I still get the same problem if I choose to install Steam on any other drive mount that happens to be in an NFS path, but I could not simply make the mountmgr override the NtQueryVolumeInformationFile result because mountmgr is always returning DRIVE_FIXED for drives with no registry key
You're wrong there, it's DRIVE_UNKNOWN, which is the autodetect thing (I haven't looked into it in detail, but something is *correctly* autodetecting your drive C: as a network drive). http://www.winehq.org/pipermail/wine-devel/2009-March/073835.html This patch to mountmgr.sys forces C: to be DRIVE_FIXED when changes are made to the config for it. It's probably not ideal in your situation, as you'd have to make define_unix_drive() get called (this happens when you apply drive settings in winecfg). http://www.winehq.org/pipermail/wine-patches/2009-March/070292.html If you combine it with this patch, you should be able to ensure that the C: drive type is set to "hd" in your registry. I'm still pretty sure kernel32 isn't the right place for forcing drive type. Maybe someone more experienced can comment?
Ben Klein wrote:
You're wrong there, it's DRIVE_UNKNOWN, which is the autodetect thing (I haven't looked into it in detail, but something is *correctly* autodetecting your drive C: as a network drive). <snip> I'm still pretty sure kernel32 isn't the right place for forcing drive type. Maybe someone more experienced can comment?
I can't think of any case where you would want C: to be reported as a non-fixed drive - I suspect Windows may behave this way even if it was installed to a removable disk - and as far as wine users are concerned, the C: drive should be a fixed drive. More importantly my patch should not introduce any secondary bugs, and that was my top priority. You say it reports DRIVE_UNKNOWN, but create_drive_devices uses this logic: drive_type = i < 2 ? DEVICE_FLOPPY : DEVICE_HARDDISK_VOL; if (drives_key) ... To me it was pretty clear that all drives without a registry value are going to show up as DEVICE_HARDDISK_VOL, which translates to DRIVE_FIXED, which means that the "auto-detect" type is not being used on drives without an override value (and winecfg stores no registry value for drives set to auto-detect, so it can only be set with regedit). I was afraid of changing that logic due to the probability of introducing new bugs, and thought that someone who knows that code should tackle that when they have time. -- LordHavoc Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces/ Co-designer of Nexuiz - http://alientrap.org/nexuiz "War does not prove who is right, it proves who is left." - Unknown "Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass "A game is a series of interesting choices." - Sid Meier
2009/3/10 Forest Hale <lordhavoc(a)ghdigital.com>:
Ben Klein wrote:
You're wrong there, it's DRIVE_UNKNOWN, which is the autodetect thing (I haven't looked into it in detail, but something is *correctly* autodetecting your drive C: as a network drive). <snip> I'm still pretty sure kernel32 isn't the right place for forcing drive type. Maybe someone more experienced can comment?
I can't think of any case where you would want C: to be reported as a non-fixed drive - I suspect Windows may behave this way even if it was installed to a removable disk - and as far as wine users are concerned, the C: drive should be a fixed drive.
More importantly my patch should not introduce any secondary bugs, and that was my top priority.
You say it reports DRIVE_UNKNOWN, but create_drive_devices uses this logic: drive_type = i < 2 ? DEVICE_FLOPPY : DEVICE_HARDDISK_VOL; if (drives_key) ...
To me it was pretty clear that all drives without a registry value are going to show up as DEVICE_HARDDISK_VOL, which translates to DRIVE_FIXED, which means that the "auto-detect" type is not being used on drives without an override value (and winecfg stores no registry value for drives set to auto-detect, so it can only be set with regedit).
You're looking in the wrong place. create_device_devices in device.c is where the ~/.wine/dosdevices/X:: links are created (where X is a drive letter). I'm looking in mountmgr.c/define_unix_drive, which defines a whole drive (not just the device link) and DEVICE_UNKNOWN is the default here. Note that DEVICE_UNKNOWN is the "autodetect" system, and the other cases that can be set via winecfg (except DRIVE_FIXED) are handled there. Take a look at this thread where drive C is being talked about again. There is debate over whether Wine should explicitly treat drive C specially, or whether it should be dynamic (like a reference based on %SystemDrive%). http://www.winehq.org/pipermail/wine-devel/2009-March/073835.html
On Sat, Mar 7, 2009 at 1:13 PM, Forest Hale <lordhavoc(a)ghdigital.com> wrote:
I happen to agree with that sentiment, but Wine creates ~/.wine/drive_c and configures it as C:, for the sake of all common users this is correct.
To force C: to be a fixed drive is not harmful in any case I can think of.
It does not help if you set up wine with an installation in another drive letter, but that is a separate issue.
Francois Gouget wrote:
On Fri, 6 Mar 2009, Forest Hale wrote:
Fixed GetDriveTypeW to always report C: as DRIVE_FIXED, preventing problems with the Steam installer if /home is a network share or other special mount.
+ if (root && (root[0] == 'C' || root[0] == 'c')) return DRIVE_FIXED;
I think you should not hardcode the c: drive here. Something based on GetSystemDirectory(), GetWindowsDirectory() or one of their relatives would be better (not sure exactly which should be used).
Please bottom post on Wine mailing lists. Just because we currently make the system drive to be c by default doesn't mean we can't support using D or some other letter does. Making your code more portable now makes this easier to do in the future. -- -Austin
participants (4)
-
Austin English -
Ben Klein -
Forest Hale -
Francois Gouget