Comment 19 for bug 565342

> The check can be disabled by creating a temporary wineprefix dir that
> contains symlinks to the real files. For an expert user that's surely not
> harder than specifying a command line option.

I know that and I even recommended doing this on wine-users mailing list some time ago as possible solution for this problem.

However what if I'm creating new WINE prefixes frequently? For example, new prefix for new set of Windows programs (sometimes there is good technical reasons for doing this, especially in multiuser setup). I need then to write a script to bypass this check and launch it for each new WINE prefix. Yes, I can do that (in fact, I'm professional Linux programmer - in other words, this is my occupation). But fixing the problem in WINE source is not only faster but more convenient (because there is no need to write a wrapper script for wineprefixcreate; and I'm recompiling WINE git tree after each update anyway).

I see no harm in adding at least command-line switch (this is very easy to implement because interaction with registry isn't required). In fact, this is traditional practice. User who didn't read the documentation will not be able to bypass the check. And user who did read the documentation (or was instructed by an expert) will be able to do what he/she want to do - without spending time for writing wrapper script or modifying the source code.

By the way, not all users who need multiuser setup are programmers. But most users can easily add an alias or command-line switch. This is especially important when helping a user to create working multiuser setup with WINE. I can easily explain how to add command-line switch (and what problems might happen because of its use) or create an alias but explaining how to create symlinks for each user is much more harder (at least that's my real-life experience). This is why I care about this problem.

My final question is: can I expect a patch adding such command-line option to be accepted?