[Bug 17619] New: GetDriveTypeW says C: is a network share if /home is an NFS share, breaking Steam installer
http://bugs.winehq.org/show_bug.cgi?id=17619 Summary: GetDriveTypeW says C: is a network share if /home is an NFS share, breaking Steam installer Product: Wine Version: 1.1.16 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: lordhavoc(a)ghdigital.com Created an attachment (id=19804) --> (http://bugs.winehq.org/attachment.cgi?id=19804) Patch to make C: always report as DRIVE_FIXED type My /home is an NFS share, this means NtQueryVolumeInformationFile returns the type of ~/.wine/drive_c as a network share, confusing installers (such as Steam). I tracked this down to a problem with GetDriveTypeW querying the volume information and not even calling get_mountmgr_drive_type in some cases (such as a network share), so any configuration in winecfg had no effect. I have attached a patch that causes C: to always report as DRIVE_FIXED, which fixes my problem, and should avoid any problems of this sort in the future. However this still means that winecfg overrides have no effect on network shares, this only fixes the most common problem of C: being considered a network share. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #1 from Austin English <austinenglish(a)gmail.com> 2009-03-06 00:21:17 --- Please send patches to wine-patches(a)winehq.org -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #2 from Forest Hale <lordhavoc(a)ghdigital.com> 2009-03-06 06:18:54 --- Okay, sent. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Forest Hale <lordhavoc(a)ghdigital.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Difficulty|--- |Minutes OS/Version|other |Linux Platform|Other |PC-x86-64 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dank(a)kegel.com --- Comment #3 from Dan Kegel <dank(a)kegel.com> 2009-03-08 00:55:52 --- How badly are the apps confused by this? Arguably this is not a bug, since in that case, the C: drive is in fact on a network drive... This might require some discussion. For instance, it might suffice to let winecfg override C's drive type. This might be easier to get past Alexandre, and would give people a workaround for now. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #4 from Forest Hale <lordhavoc(a)ghdigital.com> 2009-03-08 05:16:24 --- Steam flat out refuses to install on any drive that is not DRIVE_FIXED, so all games purchased on Steam are unusable. Fairly serious for a certain class of people (those using NFS /home and owning games on Steam). I worked on a patch for making the winecfg settings override NtQueryVolumeInformationFile but found no way to make it not universally override it - it returns DRIVE_FIXED for drives with no winecfg setting, which means NtQueryVolumeInformationFile would be overridden in all cases and that doesn't seem to be the intention. I only solved this problem in the simplest way possible for all standard wine installs. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #5 from Austin English <austinenglish(a)gmail.com> 2009-03-08 17:34:51 --- (In reply to comment #3)
This might require some discussion. For instance, it might suffice to let winecfg override C's drive type. This might be easier to get past Alexandre, and would give people a workaround for now.
Only if we can do that without also letting people reassign C. Otherwise, the floodgates of people trying to mount a windows partition as C will reopen. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Maarten Lankhorst <m.b.lankhorst(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.b.lankhorst(a)gmail.com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #6 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 2009-03-10 09:37:37 --- This patch will not get accepted. If you want a patch accepted, look what registry key is queried for the device type, and then change wine/tools/wine.inf.in for it. I think the get_drive_type function in wine/programs/winecfg/drive.c will help you to find which registry key you need to populate for this. I think that making a special case for c won't fly, but adding it in the initial registry might. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Ben Klein <shacklein(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shacklein(a)gmail.com --- Comment #7 from Ben Klein <shacklein(a)gmail.com> 2009-07-01 22:38:26 --- Forest, can you test 1.1.23 or 1.1.24 and set drive C: to be a "Local disk" in winecfg? Bug 17618 was fixed in 1.1.23. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #8 from Forest Hale <lordhavoc(a)ghdigital.com> 2009-07-02 00:17:15 --- Yes bug 17618 is fixed, however it has no direct relation to this bug. The first and most critical problem is that setting the string HKLM\Software\Wine\Drives\c: to hd still functions as autodetect (the wine code interprets a local hard drive as autodetect), this is also true of other drive letters, the overrides are ignored if they are hd. The second problem is that this is a user-visible problem in the default configuration - c: should always default to hd, not autodetect, because both the user and the applications expect c: to behave like a fixed disk. Hence why my patch forced c: to report as DRIVE_FIXED. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #9 from Ben Klein <shacklein(a)gmail.com> 2009-07-02 00:58:23 --- Can someone provide a simple test app to show whether a given drive is considered a network drive or not (using win32 API to determine it, of course :) )? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #10 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-12-10 08:33:09 --- Created an attachment (id=25155) --> (http://bugs.winehq.org/attachment.cgi?id=25155) get_disk_type.c (In reply to comment #9)
Can someone provide a simple test app to show whether a given drive is considered a network drive or not (using win32 API to determine it, of course :) )?
Here you go -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Frank Gore <gore(a)projectpontiac.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gore(a)projectpontiac.com --- Comment #11 from Frank Gore <gore(a)projectpontiac.com> 2009-12-10 18:18:02 --- Since C:\ cannot ever be a network share in Windows, then I don't see why Wine should ever present it as a network share to applications. The argument that C:\ should always be reported as DRIVE_FIXED is a valid one, regardless of whether $WINEPREFIX/drive_c resides on a network share or not. Otherwise it breaks Windows compatibility. Photoshop CS2 (Platinum-level application) also refuses to install to a network share. So it cannot currently be installed to C:\ if $WINEPREFIX/drive_c is on a network share. For the record, I also have my /home directory auto-mounted as a network share when I log in. My Wine environment resides at ~/.wine (so I can use it regardless of what computer I log in from) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #12 from Ben Klein <shacklein(a)gmail.com> 2009-12-10 18:57:07 --- (In reply to comment #11)
Since C:\ cannot ever be a network share in Windows
Is this still the case for XP/Vista/7 which allow drive remapping? (I've seen XP systems that have L: %SYSTEMDRIVE% or whatever it's called.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #13 from Forest Hale <lordhavoc(a)ghdigital.com> 2009-12-10 22:57:15 --- (In reply to comment #12)
(In reply to comment #11)
Since C:\ cannot ever be a network share in Windows
Is this still the case for XP/Vista/7 which allow drive remapping? (I've seen XP systems that have L: %SYSTEMDRIVE% or whatever it's called.)
The perspective I take on this is: the default wine install should never cause users unnecessary pain - it should enforce that the C: reports as DRIVE_FIXED, how this is done is less important. The underlying problems cause the user's settings in winecfg to be ignored, causing problems for any user attempting to force the type of additional drive mounts, but the common manifestation of this for users is C: not being DRIVE_FIXED. It is important to note that winecfg does not allow the user to modify the type of the C: drive, and registry modification in its place is not a compelling argument, at least to me. For this reason I assert that C: is always DRIVE_FIXED, unless the user tirelessly pursues an unnecessary approach. But pursuing this line of thinking, I think we can break this down to a few questions that could be answered on a test system: 1. When the OS is installed to D: on a partition setup with two NTFS partitions (respectively C: and D:), is it possible to delete the C: partition? 2. If the C: partition is deleted, can a new network mount be made as C: ? 3. If the C: partition is deleted and a network mount made as C:, what drive type does it report as? Then the question is whether the discovered behavior would be appropriate for Wine, considering that it creates its own install under much more ideal conditions than a real OS has to contend with. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #14 from Austin English <austinenglish(a)gmail.com> 2010-12-20 22:15:49 CST --- This is your friendly reminder that there has been no bug activity for a year. Is this still an issue in current (1.3.9 or newer) wine? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Walter <preparationh67(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |preparationh67(a)gmail.com --- Comment #15 from Walter <preparationh67(a)gmail.com> 2011-07-13 08:54:13 CDT --- This issue still exists in wine 1.3.24-1, patch works though and steam installs and works. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #16 from Maarten Lankhorst <m.b.lankhorst(a)gmail.com> 2011-07-13 09:00:04 CDT --- this would still leave NtQueryVolumeInformationFile reporting the wrong information, I think you want to alter that call instead. Or add a registry key for this in wine.inf.in -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download --- Comment #17 from Austin English <austinenglish(a)gmail.com> 2013-11-13 14:33:19 CST --- Still in 1.7.5. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 oiaohm <oiaohm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oiaohm(a)gmail.com --- Comment #18 from oiaohm <oiaohm(a)gmail.com> 2013-11-13 20:43:45 CST --- Forest Hale and Frank Gore is wrong. C: does not report all the time as DRIVE_FIXED in all installs of Windows. Microsoft Windows Preinstallation Environment (Windows PE) can have C: as other than DRIVE_FIXED. Yes remember Windows PE does CD forms and other forms. So fairly much everything C: can be reported as using Windows PE. Include the odd ball DRIVE_RAMDISK that we don't have the option to set in winecfg. Forest Hale in newer versions of windows C: is always the drive where windows is installed. So if you order windows to install on D: when you boot up windows D: is now C:. Now this brings us to the big problem here. Take Steam go read their documentation they don't recommend installing on network share and refuse to due to file locking issues. With steam you are meant to install to a local hard drive then copy installed files using steam backup to network share. This is instructions for Windows users of steam. nfs is not without is locking issues. No one has asked the serous question is the safe to report to applications they are on a local drive when its really a network share. The answer is most likely its not safe. One work around to this without requiring altering wine at all is http://alexeytorkhov.blogspot.com.au/2009/09/mounting-raw-and-qcow2-vm-disk-... Yes mount an image file from the nfs containing ext4. This is also coping how you are meant todo windows drive c. http://windowsdiskless.wordpress.com/ Correct way to fix this is not simple. Will require lot more test cases of disc io. Yes setting a nfs share to pretend to be local should require a set of checks to make sure the nfs share is sane to be used in this way. Like nfs can have nolock enabled and this makes nfs very much like running wine on ntfs or fat filesystems something we don't support. Yes we recommend image mounting on ntfs and fat as well to get local linux file-systems. So I am really tempted to request this bug closed won't fix. As the fixes so far open up Pandora box of issues. To fix properly requires alterations to winecfg to report if change is allowable by test cases checking for operational requirements. Sometimes drive c will just have to be other items other than DRIVE_FIXED because it will not be safe. Automatically and blindly setting C: as DRIVE_FIXED has to be out. Wine refusing to create WINEPREFIX until its given somewhere that has features required for DRIVE_FIXED would be an option. This could also fix the fat and ntfs screw up issues. Since wine would also refuse to create. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #19 from Dan Kegel <dank(a)kegel.com> 2013-11-13 20:50:44 CST --- Since C: really is a network drive in that case, and network drives do not perform like local drives, this is probably correct behavior. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #20 from Austin English <austinenglish(a)gmail.com> 2013-11-14 13:20:39 CST --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17619 --- Comment #21 from Forest Hale <lordhavoc(a)ghdigital.com> 2013-11-21 22:48:08 CST --- Thank you for noting the relevant pieces of code to patch for such an override, however at the time I had attempted to patch that function with no success, as DRIVE_FIXED could be overridden by other things, but not "reverted" back to DRIVE_FIXED, and the setup logic was convoluted to say the least. I will not assume it remains so. I have consistently found that shifting blame onto the user for configuration quirks that the user does not consider to be defects, is an entirely fruitless endeavor, that only leads to the user concluding "wine is not usable", rather than complying with the request. So my approach to this was solely focused on making wine usable for these users, no matter how technically inconvenient that solution may be. Thank you for your time. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org