You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 25, 2018. It is now read-only.
The trace back error is the same as reported in Issue #47 (July 2013), namely:
Traceback (most recent call last):
File "controls\softwareupdate.pyc", line 197, in processResults
File "esky__init__.pyc", line 721, in auto_update
File "esky__init__.pyc", line 769, in do_auto_update
File "esky__init_.pyc", line 811, in fetch_version
File "esky\finder.pyc", line 80, in fetch_version
File "esky\finder.pyc", line 221, in fetch_version_iter
EskyVersionError: 10.02
As I'm not sure whether that issue was under the same circumstances and/or resolved, I'm raising a new one.
The app is installed in Program Files which requires administrator rights to install updates. The first update installs OK but the following one results in the above error. During the first update, the need for admin rights is triggered by the failure to create the folders updates\downloads updates\ready and updates\unpack in the appdata folder. Admin rights are then requested, the process is repeated and the update completes successfully.
However, on completion the contents of the three folders are removed but the folders themselves remain.So during the next update it is not necessary to create them and consequently no permissions error is raised and there is no request for admin rights. The update continues without them, fails and eventually raises the above error.
The tidiest solution would be delete the folders themselves during the post-update cleanup but that isn't going to resolve cases where one update has already been done. In the attached patch** , each empty folder is deleted just before it would be created and, in fact, when admin rights are required, the deletion itself fails and triggers the necessary actions.
** Sorry it's a screen shot, this reporting tool won't let me upload a real .patch file.
David Hughes
Forestfield Software
The text was updated successfully, but these errors were encountered:
Traceback (most recent call last):
File "main.py", line 841, in
File "main.py", line 333, in bootstrap
File "main.py", line 360, in chainload
File "main.py", line 837, in chainload
File "Media.py", line 40, in
File "Media.py", line 36, in main
File "Media.py", line 26, in run_main
File "MainApp.pyc", line 127, in init_
File "esky__init.pyc", line 673, in do_auto_update
File "esky__init_.pyc", line 715, in fetch_version
File "esky\finder.pyc", line 80, in fetch_version
File "esky\finder.pyc", line 221, in fetch_version_iter
esky.errors.EskyVersionError: 2.1.6
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The trace back error is the same as reported in Issue #47 (July 2013), namely:
Traceback (most recent call last):
File "controls\softwareupdate.pyc", line 197, in processResults
File "esky__init__.pyc", line 721, in auto_update
File "esky__init__.pyc", line 769, in do_auto_update
File "esky__init_.pyc", line 811, in fetch_version
File "esky\finder.pyc", line 80, in fetch_version
File "esky\finder.pyc", line 221, in fetch_version_iter
EskyVersionError: 10.02
As I'm not sure whether that issue was under the same circumstances and/or resolved, I'm raising a new one.
The app is installed in Program Files which requires administrator rights to install updates. The first update installs OK but the following one results in the above error. During the first update, the need for admin rights is triggered by the failure to create the folders updates\downloads updates\ready and updates\unpack in the appdata folder. Admin rights are then requested, the process is repeated and the update completes successfully.
However, on completion the contents of the three folders are removed but the folders themselves remain.So during the next update it is not necessary to create them and consequently no permissions error is raised and there is no request for admin rights. The update continues without them, fails and eventually raises the above error.
The tidiest solution would be delete the folders themselves during the post-update cleanup but that isn't going to resolve cases where one update has already been done. In the attached patch** , each empty folder is deleted just before it would be created and, in fact, when admin rights are required, the deletion itself fails and triggers the necessary actions.
** Sorry it's a screen shot, this reporting tool won't let me upload a real .patch file.
David Hughes
Forestfield Software
The text was updated successfully, but these errors were encountered: