AppImageUpdater re-downloading same version instead of update

[luzpaz]

This may have something to do with the way FreeCAD releases but here goes:

When I run AppImageUpdater-9b4000e-x86_64.AppImage on: https://github.com/FreeCAD/FreeCAD/releases/tag/0.19_pre
specifically the current
FreeCAD_0.19-18614-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage (Note: link may not work if new version is released),
AppImageUpdater is downloading the same version and labeling it:
FreeCAD_0-revised-on-2019-10-30T07-52-00.19-18614-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage

to be clear, I'm updating a previously downloaded appimage: FreeCAD_0.19-18614-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage

[antony-jr]

@luzpaz the update information for the given AppImage is as follows,

$ strings FreeCAD_0.19-18614-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage | grep "zsync"
Wgh-releases-zsync|FreeCAD|FreeCAD|0.19_pre|FreeCAD*glibc2.12-x86_64.AppImage.zsync

As you can see the update is pointed towards the 0.19_pre tag and not the latest tag. So the updater only checks if the given file is not the same as the file in the given tag. If so it updates the current appimage with respect to the one in 0.19_pre tag.

Now, the new file is renamed with revised and a time stamp if a file with the target file name exists in the output folder, this is to avoid file name collision.

My question is, What do you want the updater to do?, Like Do you want it to update to the latest version released under the latest tag?

[luzpaz]

@antony-jr Thank you, that was educational. I'm dissapointed that when running the strings command, the revision number `FreeCAD_0.19.xxxxx isn't showing up.

In this case, a new AppImage is generated every few days against FreeCAD master HEAD. When a new AppImage is generated it will change the revision number FreeCAD_0.19.xxxxx-Linux-Conda... I want AppImageUpdater to pull the latest up-to-date revision if it's superior to the version I'm running locally.

[antony-jr]

I want AppImageUpdater to pull the latest up-to-date revision if it's superior to the version I'm running locally.

That is the problem. You see, according to the AppImageSpec. We can only sync a specific file based on SHA-1 hashes targeting a specific git release tag only as given by the Application author. The update triggers if the local and remote SHA-1 hash differs. We don't really want to get into the mess of parsing version numbers.

So the final say is that, If the remote file at git release tag 0.19_pre with the filename FreeCAD_0.19-18614-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage has a different hash than the one you have locally then the zsync algorithm is applied between your local file and that remote file only.

[luzpaz]

Ok, thanks for the explanation. Appreciate it. Closing

[antony-jr]

@luzpaz You can try asking the Application author to create a new release channel to suffice your way of release cycle.

[luzpaz]

what would I ask for specifically then ?

[antony-jr]

I think they already build the latest AppImage from master HEAD. You see when a file name collision is detected the newly created file will have a timestamp it was updated, that does not mean both files are the same. So try checking the version number inside the Application on the newly created AppImage by the Updater. The fact that the updater was triggered suggest that the SHA-1 hashes differs from the local and remote file.

I really don't know the specifics.

[antony-jr]

I am testing this right now. Will reopen this if something is wrong.

[antony-jr]

This is what you will see if the SHA-1 hash of the local and the remote file exactly matches,

So you see, I think the updater never re-downloaded the file, it actually downloaded the next version but because of the name collision it renamed it to FreeCAD_0-revised-on-2019-10-30T07-52-00.19-18614-Linux-Conda_Py3Qt5_glibc2.12-x86_64.AppImage

[luzpaz]

CC @sgrogan @triplus

[sgrogan]

I imagine it's due to the way we build the .AppImage as a Cron job. It happens that the same conda version is re-packaged. The name is the same but any timestamps would be different.

Also the 0.19_pre tag is static. It's created at the release and we deploy to the GitHub release, we do not use the source from that tag though.

[antony-jr]

I imagine it's due to the way we build the .AppImage as a Cron job. It happens that the same conda version is re-packaged. The name is the same but any timestamps would be different.

That explains everything. Due to change in timestamps within the package, The SHA-1 would differ and the updater thinks it as a update(Which is as expected). The zsync protocol itself simply syncs the target file regardless of its version, So even if its old or new, If your local file does not match the SHA-1 hash of the remote, we sync it.

So one way to fix this is not to use Cron jobs at all, or schedule the Cron job only when new commits are produced.

I think @luzpaz you should do the update in a specific time period. Like every month or so.

[luzpaz]

@antony-jr and @sgrogan thanks for troubleshooting the issue. Much appreciated.

[sgrogan]

So one way to fix this is not to use Cron jobs at all, or schedule the Cron job only when new commits are produced.

Yes, but it's not when there are new commits, but rather when the conda package is updated. @triplus (If that's not bailing out nothing is)