https://bugs.winehq.org/show_bug.cgi?id=46863
Bug ID: 46863 Summary: If prefix contains "windows" drive information not available in 64-bit prefix Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: darktjm@gmail.com Distribution: ---
All of my wine prefixes contain a path element called "windows" (actually, I use c:\windows, always). When I try to run installers or anything else that wants drive information, I get weird errors, starting with "Could not find DOS drive for current working directory" and usually ending with installer failures such as "The drive or UNC share you selected does not exist or is not accessible". Usually 64-bit games work fine once I figure out a way to install them anyway, such as direct extraction or 32-bit installs moved over.
I think I have traced it to dlls/ntdll/directory.c:lookup_unix_name. If the full unix path has "windows" in it, and redirects are possible (true for 64-bit), the stat is skipped. However, if name_len is 0, it assumes immediately after that the stat took place, and exits with an error ("drive root doesn't exist"). To fix, I changed the redirect test to add !name_len (line 2641 in 4.4):
if(!redirect || !name_len || (!strstr(....
A better fix might be to ignore "windows" if it's part of WINEPREFIX, so that the longer version of the search isn't always necessary. Since I don't know the code, I don't know how to skip over WINEPREFIX easily. With this fix, I can finally run installers in 64-bit prefixes, at least.
This bug has plagued me since I first got 64-bit prefixes working at all for myself, so around 2.0 or earlier. I only now got around to looking into it because a particular game requires a particular 3rd party installer to work in 64-bit mode, so my usual tricks don't cut it any more.
https://bugs.winehq.org/show_bug.cgi?id=46863
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- Can you share an example?
https://bugs.winehq.org/show_bug.cgi?id=46863
--- Comment #2 from Thomas J. Moore darktjm@gmail.com --- I don't know. I use my own scripts around wine to make it work better, and I'm not going to upload the scripts. Without the scripts, it's harder to reproduce in exactly the same way. In fact, I can't even get anything to start at all. Something about how I do my stuff makes it actually start, and then fail as described.
mkdir /tmp/windows cd /tmp/windows WINEARCH=win64 WINEPREFIX=/tmp/windows wine regedit /? cd dosdevices/c: ln -s ~/.cache/winetricks/xvid/Xvid-1.3.2-20110601.exe . WINEARCH=win64 WINEPREFIX=/tmp/windows wine Xvid-1.3.2-20110601.exe
Warning: could not find DOS drive for current working directory '/tmp/windows/drive_c', starting in the Windows directory. wine: cannot find L"C:\windows\system32\Xvid-1.3.2-20110601.exe"
If I use /tmp/win instead, it works fine.
Also, I'm not going to put any more effort into this. If you want to fix it upstream, fine. If not, I'll just fix it for myself. if you actually read the code I refer to, the bug is obvious.
https://bugs.winehq.org/show_bug.cgi?id=46863
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Version|unspecified |4.4 Hardware|x86 |x86-64
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- It really embodies the spirit of open-source software, doesn't it?
Anyway, I've sent a patch: https://source.winehq.org/patches/data/161949
https://bugs.winehq.org/show_bug.cgi?id=46863
--- Comment #4 from Fabian Maurer dark.shadow4@web.de --- @Zebediah Figura Do you know why it's checking for the string windows in the first place?
https://bugs.winehq.org/show_bug.cgi?id=46863
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- (In reply to Fabian Maurer from comment #4)
@Zebediah Figura Do you know why it's checking for the string windows in the first place?
The point of that function is twofold, both to determine the correct case of each path element and to resolve redirects. Since determining the correct case can be expensive, it tries to use the passed-in case first. However, if the path involves redirects, that check will be wrong, so it's skipped. As it happens all redirected files and directories live inside the C:/windows/ directory, so it works as a quick filter.
https://bugs.winehq.org/show_bug.cgi?id=46863
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |071e729969c5536e3b5958b11d4 | |3341803f6bd40 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commitdiff/071e729969c5536e3b5958b11d43341803f6bd40.
https://bugs.winehq.org/show_bug.cgi?id=46863
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.6.
https://bugs.winehq.org/show_bug.cgi?id=46863
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x
https://bugs.winehq.org/show_bug.cgi?id=46863
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |---
--- Comment #8 from Michael Stefaniuc mstefani@winehq.org --- Removing the 4.0.x milestone from bug fixes included in 4.0.2.
https://bugs.winehq.org/show_bug.cgi?id=46863
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paleozogt@gmail.com
--- Comment #9 from Zebediah Figura z.figura12@gmail.com --- *** Bug 46545 has been marked as a duplicate of this bug. ***