Comment 1 by briang1 on 2012-06-24 08:54
I'm not quite sure what you are asking for here. Surely, it always knows if its a faulty file by its checksum and won't run it if its in any way broken.
Forcing it to do so could cause issues. I'd have thought a wildcard delete of any similar files before a download would be all that was needed here, assuming you care about a few temp files.

I tend to clear this out with ccleaner in any case.
It would be more useful as mentioned in another ticket, to have an option to save the update file as the snap title as you can on portable copies, ie into the download folder.

Comment 2 by elliott94 on 2012-06-24 10:38
It doesn't look as if the launcher checks to see if it's damaged at all before launching, which was what I was suggesting; it literally started, and exited again.

I don't think this is necessarily a case of storing older downloads; after all, they may be corrupted in any case.

Comment 3 by briang1 on 2012-06-24 10:48
I've never had it start. Presumably it is run if it finds it, and if it fails the checksum or whatever windows does, it just exits and the old copy is still running at that time.
I have never found this occurs in xp though, when the downl9oad has been from a prompt to update. the file itself is in fact the same as the installer itself, just saved in a different place under a standard name for updates from what I can see.

Normally if it fails it is spotted at the downloading stage. This is usually due to a network issue I find.
A recycle of checking for updates manually after said problem is sorted makes it overwrite it in any case.

I tend to keep a portable version on the system which I get to poll for updates as this gives the option to download to a file and can be kept and also it will update the installed version as normal after the download is run, if it finds one present already on the system, or installs anew if it does not.

Comment 4 by elliott94 on 2012-06-24 11:04
In certain situations, the launcher doesn't actually get overwritten, i.e if the download failes. When the next update starts, the new launcher gets saved to the temp directory but as a different filename.

Comment 5 by mdcurran on 2012-07-02 00:27
a84ccc9 makes the NVDA launcher perform a CRC check like the old installer used to (not sure why this accidentally got dropped).
Changes:
State: closed

Comment 6 by elliott94 (in reply to comment 5) on 2012-07-02 09:40
Replying to mdcurran:

a84ccc9 makes the NVDA launcher perform a CRC check like the old installer used to (not sure why this accidentally got dropped).

I assume an error gets shown if the CRC doesn't match?

Also, I guess this should be set to 2012.3. :)

Comment 7 by mdcurran on 2012-07-02 23:21
I assume an error gets shown. That is what the NSIS documentation leads me to believe. However I must admit I'm finding it hard to come up with a way to force the CRC check to be wrong to test it.
Changes:
Milestone changed from None to 2012.3

Comment 9 by elliott94 (in reply to comment 7) on 2012-08-31 15:23
Replying to mdcurran:

I assume an error gets shown. That is what the NSIS documentation leads me to believe. However I must admit I'm finding it hard to come up with a way to force the CRC check to be wrong to test it.

If you're interested, I've attached an example of a launcher which failed to download, but was kept in the temperary directory. As you can see, the description is correct (NVDA Launcher), but not much happens when it's exicuted.

Just out of interest, are the filenames for launchers saved to the temperary directory randomly generated?

Attachment nvda_update_8s61zn.exe added by elliott94 on 2012-08-31 15:25
Description:
NVDA corrupt launcher.

Comment 10 by jteh (in reply to comment 9) on 2012-09-03 06:14
Replying to elliott94:

Just out of interest, are the filenames for launchers saved to the temperary directory randomly generated?

Yes.