http://bugs.winehq.org/show_bug.cgi?id=33931
Bug #: 33931 Summary: Steam is broken when installed on a "Local hard disk" type drive Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: gediminas@varciai.lt Classification: Unclassified
Created attachment 45070 --> http://bugs.winehq.org/attachment.cgi?id=45070 Part of terminal output
After installing Steam on a drive that is set to be "Local hard disk"[1], many of its games fail to complete installation, along with other issues. With this, many games[2] on steam start suffering from an issue nearly identical to bug #20910 Also, this appears to be the underlying cause of bugs #32894 and #32895
How to reproduce: 1. Make a new wine prefix. 2. Add a new drive 3. Select the new drive and set its type to "Local hard disk" 4. Install Steam on the said drive 5. Install any of the listed games[2] 6. Run the game and it fails to start due to a problem nearly identical to Bug #20910
Attaching only the part of terminal output which is present in with this bug triggered, but doesn't appear on "working" steam. Everything else is identical.
What's interesting - setting the drive type back to "autodetect" and then completely reinstalling steam doesn't make it work - the "new" Steam installation has the same issues nonetheless. As if the prefix itself gets incurably tainted. Thus, triggering this issue requires a new prefix to solve.
[1] winecfg => Drives => Show Advanced => Type => set to "Local hard disk" [2] Games confirmed by me to get affected: Serious Sam HD: The Second Encounter; Counter Strike: Global Offensive; Left 4 Dead 2; Though it seems all the Source engine games are affected.
Note #1: Serious Sam HD: The Second Encounter DEMO can also be used to trigger. Note #2: If someone would give me a hint where to start, I'd try to fix this myself.
http://bugs.winehq.org/show_bug.cgi?id=33931
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=33931
--- Comment #1 from Gediminas Jakutis gediminas@varciai.lt 2013-08-19 13:57:05 CDT --- This bug is also triggered if Wine has to access a directory which is symlinked to somewhere outside the "emulated volume/disk". Examples:
example #1: [wineprefix]/drive_c/windows/Fonts symlinked to /foo/bar/sharedfonts
example #2: Steam being installed under d:\steam, d: being mapped to /foo/bar/games and /foo/bar/games/steam is a symlink to ../../steamisreallyhere (which would be /foo/steamisreallyhere, and that is "outside" /foo/bar/games.)
example where it doesn't get triggered: [wineprefix]/drive_c/windows/fonts symlinked to [wineprefix]/drive_c/somedir works fine as it's within the same emulated c: drive
Unlike the previous way to trigger this bug, this one is fully reversible - removing the offending symlink or relinking it to somewhere "within the bounds" of an emulated drive makes the issue go away.
I suppose this means that "Local hard disk" setting flips off something deeper to trigger this bug instead of being the source of the problem itself.
The fact that those GetVolumePathNameW calls only appear when this bug is in action, I get the feeling Wine takes some different codepath somewhere which ends up being not-well-working. I'm going to try to dig it out where it happens and find what exactly goes wrong.
Observation #1: Let's say c:\some_dir_wine_accesses is symlink at /foo/bar/somedir, which is outside c: bounds. By default this would make /foo/bar/somedir accessible by two possible paths: c:\some_dir_wine_accesses and z:\foo\bar\somedir. But despite that, two possible paths is not the cause. As removing the default z: drive (which then leaves it with only one access path) doesn't change the behaviour at all.
Observation #2: It is triggered if Wine tries to access the symlinked directory no matter if it access any files inside it or not. A good example - symlinking the Fonts folder to an empty directory.
(The Fonts directory is very handy for triggering/testing this bug - it always gets accessed by Wine, yet contains nothing even remotely important [and is empty by default in the first place...])
http://bugs.winehq.org/show_bug.cgi?id=33931
--- Comment #2 from Gediminas Jakutis gediminas@varciai.lt 2013-10-17 16:29:05 CDT --- *** Bug 32894 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=33931
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
--- Comment #3 from Ken Sharp imwellcushtymelike@gmail.com --- What Wine version? You have not specified any version.
https://bugs.winehq.org/show_bug.cgi?id=33931
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #4 from Ken Sharp imwellcushtymelike@gmail.com --- No reply.
https://bugs.winehq.org/show_bug.cgi?id=33931
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Bruno Jesus 00cpxxx@gmail.com --- Closing invalid bugs.
https://bugs.winehq.org/show_bug.cgi?id=33931
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2@gmail.com
--- Comment #6 from Saulius K. saulius2@gmail.com --- Why was it marked as invalid, please?
-
wine-bugs＠winehq.org