[pkg-wine-party] Bug#845334: Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

Jens Reyer jre.winesim at gmail.com
Thu Jan 5 01:03:37 UTC 2017


Thanks everyone for the feedback! I've been digging through this today.

On 04.01.2017 21:11, Stephen Kitt wrote:
> On Tue, 3 Jan 2017 09:06:21 -0500, Michael Gilbert <mgilbert at debian.org>
> wrote:
>> On Tue, Jan 3, 2017 at 8:49 AM, Jens Reyer wrote:
>>> This meets my personal preference. What do others think?  
>>
>> In the long term, I think we'll end up needing to blacklist all
>> extensions with this approach.
>>
>> I'm ok with it as a temporary solution for stretch, but the ideal
>> approach would only create the files when the user explicitly tells
>> winemenubuilder to do it, rather than automatically during install,
>> upgrade, etc when the user hasn't asked for it.
> 
> I've come across http://askubuntu.com/questions/323437 which suggests a
> simpler solution: dropping the "-a" switch from the winemenubuilder.exe
> command-line in wine.inf. I haven't tried this out (yet) so I don't know if
> it affects file associations inside Wine.

I just tested this in a clean environment[1], but unfortunately it
doesn't work as required:

I created a fresh prefix and installed an application. This used to
cause the generation of the unwanted native associations, but didn't
happen now - good. And the Windows application still opened pdf's with
evince (native default for pdf).

But then I installed Foxit Reader and suddenly had the whole bunch of
native associations (pdf, htm, txt, ...).

I have verified in the code that the code which generates those is
indeed only called from "winemenubuilder -a"[2].
So it looks as if something calls "winemenubuilder -a" explicitly
(wine.inf probably only changes the default). Or is that a bug in Wine
(I'll ask upstream/file a bug)?




Then I tested to force this behavior, by making the -a switch a no-op[3]:

CAVEAT 1: This removes the option to run "winemenubuilder -a" manually
(or ignores the -a switch when doing so)! - Bad, but acceptable?

Besides that I think only the functions described in [2] are affected (=
not called), so I assume there are no side effects.

The unwanted native general purpose .desktop entries are not created.

Installing an app creates as usual its launchers on the desktop and some
specific ones in ~/.local/share/applications/wine/Programs.  Further
icons and menus/desktop-directories in ~/.local/share and ~/config.

The installed app correctly used evince for opening a pdf.

Installing Foxit Reader this time didn't generate all the unwanted
native associations (neither for pdf nor for anything else). Good.

The other app then used Foxit Reader for opening a pdf. But native apps
didn't. Good.

CAVEAT 2: Of course this also means that a file type association that is
not available natively, will still not be created if you install a
Windows applications which provides it. This would also be a problem if
changing wine.inf worked. - On the other side, many (me including) will
prefer this behavior, because they don't want Wine to touch their system
at all.

I will probably commit this tomorrow. We may add some information to the
README about this, and how to create an association manually.



Otherwise: I had missed to place the full list of extensions in my
previous patch. But basically I planned to blacklist nearly all
extensions for which Wine always creates associations (except a few ones
which seem to be Windows specific and don't have a native association
(on my system)).




[1]
Warning, this might also remove unrelated content:
rm -rf ~/.wine ~/.local/share/applications/
~/.local/share/desktop-directories/ ~/.local/share/icons/
~/.local/share/mime/ ~/.config/menus/applications-merged/


[2]
The function
 write_freedesktop_association_entry
and (not sure if it really affects my system)
 write_freedesktop_mime_type_entry
create the problematic entries.

They are *only* called from
 generate_associations
which is the only place where
 is_extension_blacklisted
(which I used in my previous patch) is used. generate_associations has
no other function.

generate_associations is *only* called from
 RefreshFileTypeAssociations (line 3332)
which is *only* called from
 wWinMain (line 3641)
and only if the "-a" switch is used.


[3]
+--- a/programs/winemenubuilder/winemenubuilder.c
++++ b/programs/winemenubuilder/winemenubuilder.c
+@@ -3638,7 +3638,6 @@ int PASCAL wWinMain (HINSTANCE hInstance
+ 	    break;
+         if( !strcmpW( token, dash_aW ) )
+         {
+-            RefreshFileTypeAssociations();
+             continue;
+         }
+         if( !strcmpW( token, dash_rW ) )



More information about the pkg-wine-party mailing list