How to hand out files of five gigabytes
Google Drive serves a stub instead of the file, the browser will not pull a download through the panel, and somebody pays for the traffic.
The site had to offer two Windows images — five and seven gigabytes. A download button, the person presses it, the file comes down. A problem that looks solved since the nineties.
At first the links pointed at Google Drive. That looked sensible: the files were already there, and a link of the form drive.google.com/uc?export=download&id=... serves the file directly. It works.
It works — on files up to about a hundred megabytes.
What happens with large files
Google scans the contents for viruses before serving them. For large files the scan is not performed, and instead of the file the service returns an HTML page with a warning and a confirmation button.
So the person presses Download on your site and lands on an intermediate Google page where they have to press again. Half of them leave, deciding the link is broken.
There are workarounds about — adding a confirmation parameter to the address. They work from time to time and stop working just as often, because Google closes them off. You cannot build a download on that: today everything is fine, tomorrow you have a stream of complaints and you are the last to hear about it.
A second problem, less obvious
Google Drive has a daily quota on outbound traffic. A seven-gigabyte file exhausts it in about ten downloads, after which the link reports that the limit has been exceeded — for everyone, until the day is out.
Cloud storage for documents and file hosting are different services. Google Drive handles the first very well and was not built for the second.
Direct links from Microsoft
Since the images are official, it seems logical to serve them straight from the Microsoft servers. Such addresses do exist, of the form software.download.prss.microsoft.com/..., and that is exactly what the official download page hands out.
I assumed they could be baked into the site and refreshed once a quarter. I checked, and I was wrong.
The links live for about a day. Each contains a token with a limited lifetime, which the Microsoft page generates on every visit. You cannot bake such an address into a site — tomorrow it is dead.
You can get around it by calling the same internal API the Microsoft page calls and redirecting the visitor to a fresh link. But that API is undocumented, it breaks without warning, and every request would come from the single address of your server and run into rate limits. Not dependable.
Storage of your own
In the end I took object storage from the same host the site runs on. It is a kind of service built specifically for serving files: a direct link, no intermediate pages, no daily limits.
Setting it up took about five minutes. Two things matter:
- Access type: public. With private access the links require a signature and a download from the site will not work.
- Room to spare. Twelve gigabytes of images will not fit a ten-gigabyte plan, and the automatic move to the next one you will notice only on the bill.
You cannot upload through the browser
The very first attempt to upload through the control panel ran into a limit: five hundred and twenty megabytes at most. That is not the limit of the storage but of the web interface — a browser copes badly with multi-gigabyte uploads.
You need a separate program. On macOS, Cyberduck did the job: free, with an ordinary window you simply drag files into. The host had a ready-made settings file — you download it, open it, the connection appears by itself and there is nothing to type in.
Twelve gigabytes went up in about ten minutes. The program splits large files into parts by itself, and the limit from the panel does not apply.
Checksums
The links worked, but one question remained — the kind worth asking yourself rather than waiting for visitors to ask it.
A person downloads six gigabytes from an unfamiliar domain and installs an operating system from it. There is no way for them to verify that this really is the original image and not something altered. All they can do is take your word for it.
A checksum solves this. You compute it on your side:
shasum -a 256 Win11_25H2_Russian_x64.iso
You get a string of sixty-four characters and publish it next to the button. After downloading, the visitor computes the sum on their side:
certutil -hashfile Win11_25H2_Russian_x64.iso SHA256
If it matches, the file is exactly the one you have. Change a single byte and the sum comes out completely different.
It also catches damage during the download. A multi-gigabyte file sometimes arrives broken, the installation falls over halfway with a vague error, and the person has no idea why. Comparing the sum answers that in a minute.
Every large project that hands out system images publishes checksums. That is not paranoia but a sign that whoever is handing them out has nothing to hide.
About the money
Something easy to miss when choosing storage: the plan usually names a price for storage, while the main cost is traffic.
Storing twelve gigabytes costs pennies. But every download is six gigabytes of outbound traffic charged to you. Twenty people a month come to a hundred and twenty gigabytes.
Work this out in advance. With visitors in the dozens the cost is acceptable. With thousands, the only sensible answer is to send people to the original source, even at the price of one extra click.
What follows from this
Somebody pays for gigabytes of traffic. Always. There are no free options — there are only ones where you have not yet exceeded somebody else limit.
Google Drive, file-sharing sites, any just-drop-the-file service is meant for a different use. While the files are small they cope. At gigabytes you get stub pages, quotas and limits you hear about from your users.
If you are handing out something heavy, take a service built for it, and count the traffic before, not after.