Patch failed to apply at second update on Windows

[quangvu3]

My application could not update without downloading the whole zip file and that happened only when the second update applied on Windows (no problem on Ubuntu and Mac OS X).

The first version, 1.0.1, was updated successfully from appname-1.0.2.win32.from-1.0.1.patch, but after that the app failed to update with appname-1.0.3.win32.from-1.0.2.patch and could be updated only after downloading the whole .zip file (around 13 MB).

If I re-installed application, it would be happily to update from 1.0.1 to 1.0.3 without the .zip file download. Yet, problem reappears when 1.0.4 patch to be applied subsequently.

[nilay]

During second update on Windows, log says following error:

Traceback (most recent call last):
File "wx_core.pyc", line 16776, in
File "autoupdate\vendor_wxlibsoftwareupdate.pyc", line 244, 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: 0.4.3.3

[nilay]

Further investigation prevails Esky do not seek root privilege on second update the way it happens on first time update when self.version_finder.has_version() throws exception making Esky.auto_update() to beg for get_root() and re-do everything again.

Hope this will help quick-fix this issue

[quangvu3]

I think there may be an issue with file permission on Windows that only happens when updating from frozen app as I couldn't reproduce it while simulating an update from codes.

[iTaybb]

This issue happens here as well. Windows 7 x64.

[iTaybb]

The problem is that:
When a second update occurs on windows, a _do_MOVE_FROM tries to copy
C:\Scripts\esky\dist\testapp\appdata\updates\unpack\tmp9v1fbj\app-0.2.win32
to
C:\Scripts\esky\dist\testapp\appdata\updates\unpack\tmp9v1fbj\app-0.3.win32

but the app-0.2.win32 folder is actually nested into a 'appdata' folder, so that's the right source path:
C:\Scripts\esky\dist\testapp\appdata\updates\unpack\tmp9v1fbj\appdata\app-0.2.win32

if you modify the paths manually before the _do_MOVE_FROM task, and turn off md5 hash checking, everything works.

[iTaybb]

An easier solution:
at _prepare_version (@ finder.py) replace self._copy_best_version(app,uppath) with self._copy_best_version(app,uppath,False).

MD5 hash checking still fails. when turned off, everything works.

[iTaybb]

I logged the MD5 hashes of each file, and found that the root app.exe file's hash is different. Every other files are identical.

Could someone else look up into it? It seems to be the limit of my knowledge...

Thanks.