http://bugs.winehq.org/show_bug.cgi?id=23321
Summary: ShellExecuteEx can fail for paths with spaces in them Product: Wine Version: 1.2-rc4 Platform: All OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 Component: shell32 AssignedTo: wine-bugs@winehq.org ReportedBy: basinilya@gmail.com CC: wylda@volny.cz
+++ This bug was initially created as a clone of Bug #7900 +++
If you pass an lpFile with space(s) in its name, and if there exists another file or directory whose path matches the lpFile truncated at any of its spaces, then ShellExecuteEx attempts to open/execute that other file instead.
Passing an lpFile with embedded quotes surrounding the path DOES help.
tests: 1) this test case is still marked for todo_wine http://source.winehq.org/source/dlls/shell32/tests/shlexec.c?v=wine-1.2-rc4#...
2) similar testcase by me http://source.winehq.org/source/dlls/shell32/tests/shlexec.c?v=wine-1.2-rc4#...
Patch exists, but not applied yet, because it removes possibly important block of code.
http://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #1 from Ilya Basin basinilya@gmail.com 2010-06-22 15:04:58 --- Created an attachment (id=29069) --> (http://bugs.winehq.org/attachment.cgi?id=29069) shell32: remove unneeded parsing of SHELLEXECUTEINFO.lpFile
http://bugs.winehq.org/show_bug.cgi?id=23321
Ilya Basin basinilya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, testcase CC| |basinilya@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23321
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|basinilya@gmail.com | Platform|All |Other OS/Version|All |other
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-23 01:51:03 --- What application is affected by this bug?
http://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #3 from Ilya Basin basinilya@gmail.com 2010-06-23 02:12:21 --- The real application affected by this bug is uTorrent: if you have 2 downloads containing, say, "foo/bar.avi" and "foo 2/baz.avi", when you double click the latter avi file, it'll open the explorer in folder "foo" instead.
http://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #4 from Stefan Leichter Stefan.Leichter@camLine.com 2010-06-23 12:48:35 --- May be a dupe of bug #19666 .
http://bugs.winehq.org/show_bug.cgi?id=23321
Ilya Basin basinilya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |basinilya@gmail.com
--- Comment #5 from Ilya Basin basinilya@gmail.com 2010-06-23 15:52:10 --- It is. Funny, in January I found your patch in some mail archive, but not that ticket.
http://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #6 from Ilya Basin basinilya@gmail.com 2010-06-23 16:00:32 --- ... or maybe not a dupe, because the path to .exe passed to CreateProcessW was correct. Don't mark it, wait a couple of dayse, while I check.
http://bugs.winehq.org/show_bug.cgi?id=23321
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #7 from Bruno Jesus 00cpxxx@gmail.com 2011-10-02 22:54:19 CDT --- Still present in 1.3.29?
http://bugs.winehq.org/show_bug.cgi?id=23321
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com AssignedTo|wine-bugs@winehq.org |fgouget@codeweavers.com
--- Comment #8 from François Gouget fgouget@codeweavers.com 2012-10-01 10:51:44 CDT --- Still present to this day.
http://bugs.winehq.org/show_bug.cgi?id=23321
Brandon Corujo haku08879@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haku08879@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23321
Ilya Basin basinilya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement
--- Comment #9 from Ilya Basin basinilya@gmail.com 2013-01-02 01:36:49 CST --- http://www.winehq.org/pipermail/wine-devel/2010-March/082554.html MF> 927 /* The following code is needed for example to resolve a shortcut MF> 928 to control panel applet "Keyboard", since this is accessed using MF> 929 "rundll32.exe shell32.dll,Control_RunDLL %1,%*" with a command line MF> 930 parameter received from ISF_ControlPanel_fnGetDisplayNameOf(). */
The next logical step would be to reproduce this on Windows XP, see if ShellExecuteEx() is called from Control_RunDLL() and the outcome of ShellExecuteEx().
http://bugs.winehq.org/show_bug.cgi?id=23321
Sergio Callegari scallegari@arces.unibo.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scallegari@arces.unibo.it
--- Comment #10 from Sergio Callegari scallegari@arces.unibo.it 2013-03-02 05:38:19 CST --- (In reply to comment #2)
What application is affected by this bug?
For instance LTSPICE.EXE.
When wine works in 64bit mode it gets installed in "Program Files (x86)" and then cannot find its own pieces (e.g. help files).
http://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #11 from Sergio Callegari scallegari@arces.unibo.it 2013-03-02 05:39:33 CST --- (In reply to comment #10)
(In reply to comment #2)
What application is affected by this bug?
For instance LTSPICE.EXE.
When wine works in 64bit mode it gets installed in "Program Files (x86)" and then cannot find its own pieces (e.g. help files).
Sorry for the mistake. The program is called LTSPICE http://www.linear.com/designtools/software/
http://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #12 from Sergio Callegari scallegari@arces.unibo.it 2013-03-02 05:43:12 CST --- Since all wine stuff with arch set to win64 may install things in "Program Files (x86)" which has a very high probability of triggering the issue, may I suggest defaulting to win32 until this is fixed?
Also please update status to NEW, since this is very easy to verify (e.g. in wine-1.5.25).
http://bugs.winehq.org/show_bug.cgi?id=23321
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com Severity|enhancement |major
http://bugs.winehq.org/show_bug.cgi?id=23321
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #13 from François Gouget fgouget@codeweavers.com 2013-03-05 07:35:13 CST --- I can confirm this bug. Here is a simpler way reproduce it with both the 32 and 64-bit builds of Wine:
$ mkdir "~/.wine/drive_c/one space" $ echo Works >"~/.wine/drive_c/one space/file.txt" $ ./wine start "c:\one space\file.txt"
-> This opens the file in notepad and you should see "Works".
$ mkdir "~/.wine/drive_c/one" $ ./wine start "c:\one space\file.txt"
-> Now you get explorer.exe browsing the "One" directory. This is clearly not what you want and this is caused by this bug.
A WINEDEBUG=+exec shows:
trace:exec:SHELL_execute mask=0x00008500 hwnd=(nil) verb=L"open" file=L"C:\One Space\File.txt" parm=L"" dir=(null) show=0x00000001 class=not used fixme:exec:SHELL_execute flags ignored: 0x00000100 trace:exec:ShellExecute_FromContextMenu L"C:\One Space\File.txt" trace:exec:ShellExecute_GetClassKey ext = L".txt" trace:exec:ShellExecute_GetClassKey class = L"txtfile" trace:exec:SHELL_execute execute:L"C:\One Space\File.txt",L"",L"" trace:exec:SHELL_ExecuteW Execute L"C:\One Space\File.txt" from directory L"" trace:exec:SHELL_ExecuteW returning 5 trace:exec:SHELL_FindExecutable L"C:\One" trace:exec:SHELL_FindExecutable SearchPathW returned non-zero trace:exec:SHELL_FindExecutable returning L"" trace:exec:SHELL_FindExecutable L"explorer" ...
http://bugs.winehq.org/show_bug.cgi?id=23321
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #14 from Sergio Callegari scallegari@arces.unibo.it 2013-06-18 04:10:56 CDT --- Bug is still there in the 1.6 RCs.
If I understand correctly, what happens is that when there is a space in a path, a call to execute the file pointed to that path will actually and unexpectedly result in executing a file residing at the location pointed by the path truncated at the space (if it exists)
I have a bad feeling that this could be exploited maliciously, forging situations where the user thinks he is doing this and instead ends up doing that.
http://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #15 from Vincent Povirk madewokherd@gmail.com 2013-10-30 17:32:05 CDT --- I did some testing on Windows, and it seems that the reverse of the case this bug is concerned about (make a file named "one" and try to execute file "one two" that does not exist) does not work.
But I'm not sure we can get rid of that code yet, because SHELL_translate_idlist can return a command line string that needs to have the filename located and separated from its arguments. Maybe kernel32 can do this, but I'm out of time for the day.
https://bugs.winehq.org/show_bug.cgi?id=23321
--- Comment #16 from Austin English austinenglish@gmail.com --- *** Bug 32833 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=23321
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #17 from Sebastian Lackner sebastian@fds-team.de --- Is this a duplicate of https://bugs.winehq.org/show_bug.cgi?id=19666 ?
https://bugs.winehq.org/show_bug.cgi?id=23321
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |focht@gmx.net Hardware|Other |x86 Resolution|--- |DUPLICATE OS|other |Linux
--- Comment #18 from Anastasius Focht focht@gmx.net --- Hello Sebastian,
yes, I'd say so.
Comment #4 indicated this and but then it goes back and forth ("dupe?" "maybe" .. "maybe not" ...) because the patch from bug 19666 was not correct at that time.
The Wine-staging patch works for the example given in comment #13 and will likely work for LTSpice, too.
Doesn't make sense to keep two bugs about the same issue...
Regards
*** This bug has been marked as a duplicate of bug 19666 ***
https://bugs.winehq.org/show_bug.cgi?id=23321
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Béla Gyebrószki gyebro69@gmail.com --- Closing all abandoned/duplicated/invalid bugs.
-
wine-bugs＠winehq.org