search

AppImageCommunity / AppImageUpdate

AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself.
https://appimage.org
MIT License
572 stars 57 forks source link

Appimage cause same byte site of the image even different version of the app #199

Closed slrslr closed 2 years ago

slrslr commented 2 years ago

https://github.com/AppImage/AppImageKit/issues/1175

TheAssassin commented 2 years ago

The original issue just contains a messy and hardly understandable description. What is your issue? What do you want to achieve?

Creating a issue in some other repository without any content (no, that link is not sufficient!) is not good style either. If you want help, provide a proper question.

probonopd commented 2 years ago

AppImageUpdate does not suffer from this issue. Did you even try it?

slrslr commented 2 years ago

What is your issue? What do you want to achieve?

I will not waste the space there by duplicating what was said. Issue is described when you follow the link/s. Just shortly to answer the question, issue is the same byte size of two appimages even it does not contain same data and "wget -N" unable to find out difference thanks to that. Linked description is better than what i am writing there.

Did you even try it?

i prefer wget, curl

TheAssassin commented 2 years ago

Did you even try it?

Why are you posting an issue in AppImageUpdate if you're not using it?

I will not waste the space there by duplicating what was said.

What you said makes little sense. Might be some language barrier issue... You wrote "site" for instance, but mean "size".

Just shortly to answer the question, issue is the same byte size of two appimages even it does not contain same data and "wget -N" unable to find out difference thanks to that. Linked description is better than what i am writing there.

As @probonopd pointed out, that is not an issue with the AppImage, but with wget respectively your HTTP server. You should read the wget manual. All -N does is compare the timestamp of the server against the mtime of the local file. It doesn't compare file size, assuming so proves you haven't checked the manual.

Given there is still no information on what you're really trying to accomplish (no, the issue you linked to doesn't contain any useful information, and I'm not going to play link-hopping just because you're too lazy to write a proper bug report). @probonopd already mentioned AppImageUpdate is the proper way to update AppImages, it is significantly more efficient due to using a binary delta approach.

I was reluctant to reply at all, because you don't behave like someone seeking for help from people who kindly invest some of their time into your issue. You should think about how to report bugs and ask questions...

slrslr commented 2 years ago

@TheAssasin i see you are not interested to understand and had no un-aswered questions to me, so i will not explain to you the issue as it may be the waste of time. If you have though additional question to what i have written or linked (and not lazy to click a link) i will gladly answer.

i do not think wget works only with timestamp as you claim, explanation

TheAssassin commented 2 years ago

You did not post your version, a random man page didn't state this that clearly. You may be right there. The man page is a bit messy...

Still, this is a wget limitation. You make the assumption that AppImages must differ in size, but they may not. Your assumption is wrong. It's not AppImageKit's task to fix that wget limitation. The file size is defined by the contents only, and is block-aligned. If the content size does not change at least by one block size, the AppImage's size will not change.

You may be able to find a wget or curl parameter mix that does what you want, but you need to ask those communities.

AppImageUpdate is superior because it doesn't rely on timestamps, but diffs the contents.

Pro tip: do not rely on undocumented behavior. Nobody's ever made guarantees that the size would change.

probonopd commented 2 years ago

i prefer wget, curl

Which is fine but in this case you would need to discuss this with their authors ;-)

slrslr commented 2 years ago

Just wanted to highlight rare highly on-topic detail out of this topic regarding AppImage. Author used his brain and tried to understand, thanks.

The file size is defined by the contents only, and is block-aligned. If the content size does not change at least by one block size, the AppImage's size will not change.

And if this behavior is changed, wget -N would work due to diff. size likely.

discuss this with their authors

authors claims wget checks based on timestamp and file size as i already said in this topic, yet your software makes same size packages (as Assasin mentioned and as highlighted in this comment of mine) even there were substantial amount of modifications https://github.com/mifi/lossless-cut/releases/tag/v3.43.0 so wget seems unusable. Yet you do not seem to be interested to change this behavior. Thank you @probonopd for the tip of https://appimage.github.io/AppImageUpdate/ i will check it. ♥️

TheAssassin commented 2 years ago

Yet you do not seem to be interested to change this behavior.

Again: the size is defined by the contents. There is no way to "fix" this, because this is NOT a bug. "Substantial changes" does not mean the size of the contained files has to change. The sum matters.

Talk to wget folks about whether there is a combination of flags that eliminates the file size check.