Alexandre Julliard julliard@winehq.org wrote:
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.
Please file bugs for these things.
Some of the bugs were already reported, some things were observed long time ago and are no longer an issue. But once bad thing happens you can't blindly trust that a similar thing won't happen anymore in future.
And honestly, if you want to make sure things keep running, upgrading the dlls but not the prefix doesn't sound like a good idea. Just stick to the old working version.
We are forced to still support things like the prefixes created with wine-1.5.25, and most of the time such prefixes with disabled updates work perfetly with wine-3.14.
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.
I'm not sure that I see why you'd even be watching for changes, since an old prefix won't have a configured scheduler service.
An application updater enables the service. The thing is that in old Wine versions this didn't work, but with new Wine the things started magically work, including automatic application updates, and all that remains to be added is c:\windows\tasks.
I'd really appreciate if this patch gets accepted.