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.