win7x64-ultimate iso redownloaded every time the script is run with 'all' argument about mido HOT 5 OPEN

For saving bandwidth, perhaps the desired functionality could be implemented like this: https://www.cyberciti.biz/faq/linux-unix-curl-if-modified-since-command-linux-example/

We would have to verify that MS servers will cooperate with the If-Modified-Since header though. We could also the last modification time of each already downloaded ISO to avoid non-portable writing of that timestamp to a separate file. One can also get the HTTP status returned by curl using -w "%{http_code}" (to detect 304 Not Modified).

I don't have any plans of doing this, but it's up for grabs if someone wants! Feel free to verify any requirements @sysfu.

Update: On second thought, giving away an exact timestamp of the last download could lead to unique identification of users. Instead, checking the Last-Modified response header with a --head request if a downloaded ISO already exists then doing the timestamp comparison on our side before deciding whether to request an updated file download would be much more privacy friendly.

from mido.

As the script progresses, it looks like it's redownloading the win10x64-enterprise-eval.iso as well, so I assume it's going to re-download every other iso that was completely downloaded on the prior run.

from mido.

If you specify the all argument (or any argument when the requested media has already been fully downloaded) then Mido will attempt to download it again as you requested. Mido has no way to know if the already successfully downloaded media has been updated on the server since the last download so this behavior seems reasonable to me. Microsoft doesn't provide any mechanism (AFAIK) to check if the media has been updated in advance of downloading.

Perhaps it would be possible to check the Last-Modified or ETag HTTP response headers to see if the file has changed since last successful download (do MS servers send these response headers?) and only if it has then download the new version. However, this means we would then have to write that data somewhere making Mido less portable. Also, I'm not sure if curl has support for this or not (if it has some built-in functionality for this then perhaps we could easily just throw it in as an option to the curl command in the scurl_file function).

If I understand your ask correctly, I'm not sure implementing a feature to make Mido work how you would expect it to would be worth the complexity it introduces.

from mido.

Mido has no way to know if the already successfully downloaded media has been updated on the server since the last download so this behavior seems reasonable to me.

mido.sh script already contains the sha256 hash values for all iso files. Would it be a headache to test for the existence of each iso, compare the hash, and only download if either of the first two tests failed?

From my lowly end user standpoint it's counter intuitive and a waste of time and bandwidth to re-download existing and known good (and large!) iso files every time the command is run.

Perhaps an additional argument such as allfresh could be created that bypasses the above proposed file checks and forces re-downloading of all iso files.

I'll contribute $50 towards this feature.

from mido.

The problem with relying on the SHA-256 hashes is that those values are hardcoded into the script itself. They need to be manually updated when, for example, Microsoft issues a new release for win10x64. They therefore cannot be used as markers for whether or not the most up-to-date release of an ISO has been downloaded.

When originally writing Mido, I considered whether I should include the all option in case someone mistakes it for being more "intelligent" than it really is as you did. I'm leaning towards simply removing the all option.

from mido.