[PATCH] schedsvc: In case it's an old Wine prefix create c:\windows\tasks automatically.
This patch helps to avoid manual creation of c:\windows\tasks in old Wine prefixes a user may have around. Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/schedsvc/svc_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dlls/schedsvc/svc_main.c b/dlls/schedsvc/svc_main.c index 8830d59970..81f5d321ae 100644 --- a/dlls/schedsvc/svc_main.c +++ b/dlls/schedsvc/svc_main.c @@ -74,6 +74,9 @@ static DWORD WINAPI tasks_monitor_thread(void *arg) GetWindowsDirectoryW(path, MAX_PATH); lstrcatW(path, tasksW); + /* Just in case it's an old Wine prefix with missing c:\windows\tasks */ + CreateDirectoryW(path, NULL); + htasks = CreateFileW(path, FILE_LIST_DIRECTORY, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OVERLAPPED, NULL); if (htasks == INVALID_HANDLE_VALUE) -- 2.17.1
Alexandre Julliard <julliard(a)winehq.org> wrote:
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
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. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
Alexandre Julliard <julliard(a)winehq.org> wrote:
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
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. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)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. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
Alexandre Julliard <julliard(a)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. If a prefix update breaks the drive configuration, that's a bug that should be fixed. Running recent dlls against obsolete config data is not something we should try to support. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)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.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
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. 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.
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. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)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. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
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.
I'll put it in, but I'd strongly suggest that you reconsider your approach to upgrades. I'm not going to accept more complicated workarounds for obsolete prefix data. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard <julliard(a)winehq.org> wrote:
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.
I'll put it in, but I'd strongly suggest that you reconsider your approach to upgrades. I'm not going to accept more complicated workarounds for obsolete prefix data.
Thanks! -- Dmitry.
participants (2)
-
Alexandre Julliard -
Dmitry Timoshkov