Arch_Online installer discards download after being blocked

[Jarten0]

P.S. This isn't a bug, but it's some basic missing functionality that would be very helpful.

I was using the ArchOnline installer for v24.3.31.0, and it was blocked by Microsoft Defender after downloading the entire file and then attempting to install, resulting in MS Defender killing the terminal process.

That's fine, I thought, but the installer doesn't cache the download, forcing me to redownload it. It shouldn't be as big a deal as it is, but low bandwidth issues are causing more of a hassle than it should be, especially for an error as common as forgetting to disable MS Defender before running the executable. From my (in)experience a simple fix would be to cache the download after completion, so that should an error stop the process, it's easy to try the installation again, which would be especially useful in a scenario where many different errors could pop up from improper setup.

Enviroment:

• Windows build number: 10.0.19045.4291
• Security Software: MS Defender with Real-time protection enabled
• WSL version 1/2: WSL2
• ArchWSL version 24.3.31.0
• ArchWSL Installer type zip/appx/other clean/update: Arch_Online.zip

[BMurri]

Defender is blocking because it is (rightly or wrongly) detecting Trojan:Win32/Vigorf.A in the rootfs tar.

[delverofsecret]

The zip version is being flag by defender on my system to.

[Jarten0]

Defender is blocking because it is (rightly or wrongly) detecting Trojan:Win32/Vigorf.A in the rootfs tar.

Yes, it's an issue with the installer, but thats not the purpose of this issue. This issue exists to suggest caching functionality for someone familiar with it to implement. If you want to, you can open a seperate issue about it.

[yuk7]

Should I implement caching?
Sure, it can be a bit annoying to have to re-download the necessary files after a failed installation.
(I figured that would only happen a little bit, so I didn't worry about it.)
I don't think it would be difficult to implement caching.

PS: I created a new build 24.4.26.0 and the file is no longer being false positiveed by defender.