Do not create "revised-on" if we already have the "new" file

[probonopd]

Please do not create "revised-on" if we already have the "new" file, and it is the exact same file (as per its hash) as the "revised-on" one.

Example:

# This is what I already have locally
me@host:~/test$ ls
AppImageUpdater-7420c48-x86_64.AppImage  AppImageUpdater-9b4000e-x86_64.AppImage

# This is the command. Note that I am trying to update the older AppImage (9b4000e) despite that I already have the currently latest version (7420c48):
me@host:~/test$ ./AppImageUpdater-7420c48-x86_64.AppImage -n -d ./AppImageUpdater-9b4000e-x86

# This is the result
me@host:~/test$ ls
AppImageUpdater-7420c48-x86_64.AppImage
AppImageUpdater-7420c48-x86_64-revised-on-2019-11-10T13-33-00.AppImage
AppImageUpdater-9b4000e-x86_64.AppImage

#  The two files are identical:
me@host:~/test$ diff *7420c48*
me@host:~/test$ 

In this case, I do not need a second copy of what I already have. Only the mtime of AppImageUpdater-7420c48-x86_64.AppImage should maybe be updated to reflect that we had worked on this version, although this is debatable.

[luzpaz]

Related: #17

[antony-jr]

I think this can be fixed if we hash the existing file with the same target file name. But that would be expensive if the file is too large. I'm doing a rewrite so I think I can fix this some time along the way.

[probonopd]

Would need to check the checksum of the "old" file to make sure that it is really the same as the "new" file.

[antony-jr]

Would need to check the checksum of the "old" file to make sure that it is really the same as the "new" file.

So the old file must only be touched(changing the mod time) and no update should be done. No rename or anything?

[probonopd]

Yes, I'd say that is the desirable user experience.