[1.8.3] Versionless: .jarv prevents updating .jar if getdown.txt is replaced with fresh stub and digests, .jar and .jarv are remaining

[Maia-Everett]

I had a getdown installation that downloaded the digests, but didn't update appname.jar despite it being outdated. After inspecting the directory, I saw an empty appname.jarv file with an old date (same date as the outdared jar). After I deleted the jarv file, the jar got redownloaded and updated, but then the jarv file got recreated.

I'm not sure why the existence of the jarv file prevented the jar file from being updated.

There is also an empty gettingdown.lock file with an old creation date. It's not being deleted when getdown launches the application.

[Maia-Everett]

It seems this is by design - apparently versionless mode doesn't update at all after creating the .jarv file, despite downloading the new digest files?

Is there a way to force Getdown to always check the .jar file against the updated digest, regardless of the presence of a .jarv file?

[samskivert]

If the digest.txt file is detected as changed, Getdown will delete all the v files and revalidate all code and resources and the getdown.txt file against the updated digest. So if that's not happening, then Getdown is not detecting an updated digest.txt file.

[samskivert]

If you have a log file that shows Getdown downloading a new digest.txt file but then failing to revalidate all the resources against that file, that's definitely a major bug (and would render Getdown totally useless for everyone, so I'd be super surprised to find such a bug, but maybe there's something else you're doing that's triggering it). So please attach that log file and I can take a look at it.

[Maia-Everett]

I've pinned down the specific scenario under which this happens.

I have a stub getdown.txt (with just appbase) distributed with the installer, and the jar is not distributed with it. Normally the application updates correctly, but if I reinstall it (without deleting the previously downloaded jar, jarv, digest.txt and digest2.txt), it overwrites getdown.txt with the stub, and it seems to confuse Getdown somehow when the app updates. It downloads the new digests and overwrites the old ones, but doesn't re-download the jar, considering it validated. Deleting the .jarv forces Getdown to revalidate and re-download the jar.

A workaround is to have the installer delete getdown files on install and uninstall, so the app always redownloads fresh after reinstalling.

If you need, I can try and prepare a minimal example.

launcher.log

[samskivert]

Ah, I see. When Getdown notices that the getdown.txt (or digest.txt) is out of date, it clears all the validation files, but it does not just delete every file in every directory that ends with v because that would be dangerous. It uses the old getdown.txt file to know what resources exist and deletes only the validation files for those resources.

So when you overwrite getdown.txt for a fully installed app with a stub getdown.txt, then Getdown no longer knows what resources were previously downloaded so it has no way to know what validation files to delete.

I have been considering moving the validation files into a special subdirectory (or maybe just a file), and doing this would enable Getdown to clear out all validation files at once without having to know what resources previously existed. I'll leave this issue open as a reminder to do so, but you should probably stick with your workaround for now if you need to support a scenario where you reinstall a stub getdown.txt over a previously operational getdown.txt file.

[Maia-Everett]

This is reasonable. However, when Getdown uses the stub getdown.txt to download a complete getdown.txt and digest.txt, it can use those files, after they're downloaded, to know which validation files to delete.

But going forward, a separate directory for validation files seems good to me — for architectural cleanness if nothing else, so Getdown can tell its own files from the application's files.

[samskivert]

That's a fair point. I'll look into whether it might be easy to ensure that it uses the newly downloaded getdown.txt to enumerate the resources that need to be invalidated.