[PATCH] schedsvc: In case it's an old Wine prefix create c:\windows\tasks automatically.

[Dmitry Timoshkov]

Alexandre Julliard <julliard at winehq.org> wrote:

> >> >> > This patch helps to avoid manual creation of c:\windows\tasks in old Wine
> >> >> > prefixes a user may have around.
> >> >> 
> >> >> Why wasn't it created from wine.inf on prefix update?
> >> >
> >> > As far as I understand prefix update sometimes was intentionally disabled
> >> > mainly to avoid installing new versions of gecko and breaking changed drive
> >> > configuration. There are also other issues with automatic prefix updates.
> >> 
> >> I'd say that's a case where you get the keep the pieces if it's
> >> broken. I don't see a need to add workarounds in the code for broken
> >> prefixes.
> >
> > The prefix is not broken, contrary, the intention is to avoid breaking it,
> > and the prefix updates are known to break the custom configured things like
> > folder and drive configurations besides other things. Some customers have
> > their prefixes created years ago with very old versions of Wine, and things
> > still work. It would be a major pain if their prefixes got broken by an
> > unwanted prefix update.
> 
> If you consider all the things that get updated on prefix updates, and
> all the places that depend on the prefix being updated, I'd say they are
> extremely lucky if things still work.

When a prefix update is really necessary it's always performed, but only 
if the testing shows that's the case.

> If a prefix update breaks the drive configuration, that's a bug that
> should be fixed.

Drive and folders configuration is really a very small thing to worry about.
I've observed situations when a prefix update installs wine-mono to a prefix
with installed .net with predictable results, or suddenly a gecko update
completely ruins a previosuly fine working application. Sometimes it's not
always possible to fix the things afterwards, and the only way to cure it
is a full reinstall, that's why the automatic updates get disabled.

> Running recent dlls against obsolete config data is not
> something we should try to support.

If the support doesn't need a lot of efforts why not provide it to our users?
In this particular case it's just a matter of making sure that a directory
exists before starting watching its changes.

-- 
Dmitry.