Part of the provisioning steps for each template downloads ultradefrag v7.0.2 and uses it to defragment the hard disk prior to completion. This is done by using the floppy/_download.cmd script to fetch the correct zip file based on the architecture, and then using 7zip to extract and run it. When downloading from sourceforge.net, sourceforget apparently looks at the user agent and uses that to determine whether to return a binary or a webpage with a meta-redirect. This results in some downloaders failing at downloading the archive and getting an html page instead. Specifically, this symptom affects both the powershell and curl fallback downloaders and occurs nearly all the time when using the W7 templates. I imagine this affects bitsadmin in the templates too, but haven't tested that particular variation because bitsadmin sucks.
This PR fixes the issue by pointing the download url for ultradefrag to one of the redirects that sourceforge gives you (fixes powershell), and by emptying the user-agent header in the downloaders headers that get sent to sourceforge.net (fixes curl). This should result in the redirects properly getting us to the actual .zip we're asking for. Both the downloader and the file that's downloaded are sanity-checked anyways, but this does a better job of guaranteeing that the defragmentation step will occur.
Part of the provisioning steps for each template downloads ultradefrag v7.0.2 and uses it to defragment the hard disk prior to completion. This is done by using the
floppy/_download.cmdscript to fetch the correct zip file based on the architecture, and then using 7zip to extract and run it. When downloading from sourceforge.net, sourceforget apparently looks at the user agent and uses that to determine whether to return a binary or a webpage with a meta-redirect. This results in some downloaders failing at downloading the archive and getting an html page instead. Specifically, this symptom affects both the powershell and curl fallback downloaders and occurs nearly all the time when using the W7 templates. I imagine this affects bitsadmin in the templates too, but haven't tested that particular variation because bitsadmin sucks.This PR fixes the issue by pointing the download url for ultradefrag to one of the redirects that sourceforge gives you (fixes powershell), and by emptying the user-agent header in the downloaders headers that get sent to sourceforge.net (fixes curl). This should result in the redirects properly getting us to the actual .zip we're asking for. Both the downloader and the file that's downloaded are sanity-checked anyways, but this does a better job of guaranteeing that the defragmentation step will occur.
This closes issue #253.