[rewrite] Do not leave .zs-old files around about appimageupdate HOT 22 OPEN

Rewrite does cleanup its backup files as of 4b1e3a3.

from appimageupdate.

Still an issue if you already have the new version downloaded. #36

from appimageupdate.

That issue originates from your idea to keep the old files and create a new one with the new filename. When there's a file called like the new filename, it will be backed up to avoid deleting it.

A "fix" for this would probably be to make the update check look whether there's such a new file, and whether it is equal to the server file. This avoids unnecessary updates.

from appimageupdate.

Just having two identical filenames does not mean that the content is necessarily the same. If your proposal takes this into account, then I am all for it.

from appimageupdate.

The idea is to apply the selected update check to this file, too, yes.

from appimageupdate.

This has probably been resolved since AppImageUpdate checks for updates before starting an actual update now. Please confirm.

from appimageupdate.

Did not encounter it recently, hence closing. Should reopen if the problem appears again. Thanks.

from appimageupdate.

AppImageUpdate-382-b61bee3-x86_64.AppImage still leaves around .zs-old files.

Let's do some check before exiting to clean up any remaining .zs-old files.

from appimageupdate.

That issue originates from your idea to keep the old files and create a new one with the new filename. When there's a file called like the new filename, it will be backed up to avoid deleting it.

from appimageupdate.

In the end, please let's make sure that no zs-old files are around anymore in any circumstance. Whatever happens.

from appimageupdate.

i don't intend to delete files with the same filename during updates. Tell the upstream to either do proper versioning and put the version number in the new file's filename.

Quoting you:

Just having two identical filenames does not mean that the content is necessarily the same. If your proposal takes this into account, then I am all for it.

from appimageupdate.

I have the following use case quite frequently:

Same application version, newer AppImage packaging.

from appimageupdate.

zs-old screams "error", "bug" at me.

from appimageupdate.

That's nothing we could fix. .zs-old just tells "previous file", not "error".

from appimageupdate.

Why can't it then just append ".old" to the original filename, or something like that. I really dislike that "zs" thing. Our users don't know (and should not have to know) anything about "zs".

from appimageupdate.

Because that extension is coming from zsync2, which retains compatibility with zsync.

from appimageupdate.

I know, but AppImageUpdate could should "catch" these files imho.

from appimageupdate.

By the way:

i don't intend to delete files with the same filename during updates. Tell the upstream to either do proper versioning and put the version number in the new file's filename.

We should think about this.

Just having two identical filenames does not mean that the content is necessarily the same.

That is correct.

But what is the intended behavior when running AppImageUpdate?

In my opinion, if everything goes well, there should be a new file with the new filename as specified by the author of the zsnyc file. If that is a new filename (e.g., with a new version number) then this file should be there in addition to the original file.

But if this is not a new filename (but rather an existing filename), shouldn't we overwrite the existing file with the new file (after we know the update was successful) and not leave an old file around? After all that seems to be what was wanted by the zsync file author.

Not 100% on what's the best thing to do here.

from appimageupdate.

I know, but AppImageUpdate could should "catch" these files imho.

How?

But if this is not a new filename (but rather an existing filename), shouldn't we overwrite the existing file with the new file (after we know the update was successful) and not leave an old file around?

Back when we developed this, you were a fan of keeping the old files around. If the new version doesn't work, you can still use the old AppImage...

After all that seems to be what was wanted by the zsync file author.

Not necessarily. And I don't think they should get that much control.

from appimageupdate.

Back when we developed this, you were a fan of keeping the old files around. If the new version doesn't work, you can still use the old AppImage...

True. I was thinking about files with a new name though.

Not 100% on what's the best thing to do here.

Still holds ;-)

from appimageupdate.

I don't think this is really an issue. The file contains old, and will be created after an update. As a user, I'd quickly recognize "oh, it's a backup".

from appimageupdate.

This is what https://github.com/antony-jr/AppImageUpdaterBridge does and I think it's not the worst idea:

from appimageupdate.