http://bugs.winehq.org/show_bug.cgi?id=13553
Summary: Selecting a drive results in Please Insert Disk dialog Product: Wine Version: 1.0-rc2 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: karllinuxtest.relton@ntlworld.com
Created an attachment (id=13491) --> (http://bugs.winehq.org/attachment.cgi?id=13491) The graphic file selector dialog
In Greetings Card Factory, a typical operation is to add a graphic from a file.
The application has its own dialog box for this which previews a range of graphics built into the installation. At the top it has a box to allow you to specify other drives or folders. This pulldown list includes the 'drive_c' and the Linux users' home folder - populating sensibly from .wine/dosdevices it would seem.
However clicking on one of these to navigate the folder now brings up a dialog box with the message 'Please insert disk' with buttons 'Retry' and 'Cancel'. Of course there is no disk to insert (this is not a CD-Drive we are selecting), and so neither of the two buttons do anything useful. Accordingly the user cannot navigate either drive_c or their Linux home folder.
This use to work fine in the wine-0.9.x series. It is in the recent 1.0-rcX releases that it has 'broke' - and thus seems a regression.
I'll add a couple of screenshots. Unfortunately there is no easy demo installer for this app, but I'm happy to help debug.
I guess there is a certain module that it is likely to be?
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #1 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-05-30 14:00:30 --- Created an attachment (id=13492) --> (http://bugs.winehq.org/attachment.cgi?id=13492) Showing the please insert disk dialog
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #2 from Juan Lang juan_lang@yahoo.com 2008-05-30 14:34:23 --- Please do a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=13553
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #3 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-05-31 06:05:23 --- It seems I was wrong about which version it last worked in - since I tried 0.9.49 and it had the same problem.
This means the issue came in much earlier - I'll keep hunting.
Meanwhile I have narrowed it down to somewhere in shell32 shlwapi setupapi shfolder
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #4 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-05-31 06:08:49 --- Okay - I've now narrowed it to SHELL32
http://bugs.winehq.org/show_bug.cgi?id=13553
Karl Relton karllinuxtest.relton@ntlworld.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mjung@iss.tu-darmstadt.de
--- Comment #6 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-06-24 15:10:51 --- I think the commit that starts the problems was:
9393580ab5dc5dda96b5ade1446d1adbabe4bcaf
If the unixfs is rooted at the Desktop folder, forward ParseDisplayName calls to it instead of to MyComputer.
For some reason the Greetings Card Factory program, with its own folder browsing gui, is not happy with the pidl that is returned from the 'unixfs' world instead of the traditional 'mycomputer' world.
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #7 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-06-24 17:32:54 --- Well hey diddle diddle.
I did various hacky experiments, and then some lateral thinking - from the log the only thing the application is really doing (at the point of displaying its gui) is a SHGetFileInfoW with flags=0x200:
trace:shell:SHGetFileInfoW L"u:\" fattr=0x0 sfi=0x32c238(attr=0x7bca29e5) size=0x2b4 flags=0x200
Thus it is only requesting the 'displayname' of the path. Now assuming the application isn't being naughty, and assuming this function returns more than requested, what could there be in the returned displayname that might be of significance?
Well I tried engineering it so that the returned displayname would end with a colon ':' character (mkdir $HOME/test: ; ln -s $HOME/test: $HOME/.wine/dosdevices/t:).
Then selecting t: in the gui worked - no prompt for please insert disk!
So the application is simply looking at the returned displayname, and deciding based on whether it has a trailing ':' character!!
So I guess the application is bad in itself, and wine can't necessarily help it.
The only way I can see of working round this problem (without kludging in native dlls for shell32 and friends) is to have a per-app switch to disable the unix shell folder functionality.
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #8 from Vitaliy Margolen vitaliy@kievinfo.com 2008-06-29 01:19:51 --- You should still be able to use "Z:" drive to access everything. Is that not working either?
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #9 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-06-29 14:11:22 --- No - with Z: drive it says 'Please insert disk /'.
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #10 from Austin English austinenglish@gmail.com 2008-12-29 10:56:36 --- Is this still an issue in current (1.1.11 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=13553
--- Comment #11 from Karl Relton karllinuxtest.relton@ntlworld.com 2009-01-14 15:34:02 --- Yes - still gives the same problem.
I think it will always give this problem, because the application seems to be at fault in expecting a ':' after the base directory name.
The only solution I can see is to provide a (per app) user switch to revert unix shell folder functionality for this app.
http://bugs.winehq.org/show_bug.cgi?id=13553
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |ABANDONED
--- Comment #12 from Austin English austinenglish@gmail.com 2009-07-21 14:51:01 --- Abandoned. If you still have a problem in current (1.1.26 or newer) wine, and can provide the needed information, feel free to reopen.
http://bugs.winehq.org/show_bug.cgi?id=13553
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Austin English austinenglish@gmail.com 2009-07-21 15:12:02 --- Closing.