This is twice now that this has happened. bin1 for both Drakensang and Dawn of Magic 2 were corrupted files when trying to install.

The 2nd download of the files and attempting to install did not have any issue. However this is a huge issue if I were to download a massive game with 40gb+ worth of files. That's a lot of time wasted.

I did compare the files for both downloads of each game and the 1st download had slightly smaller file sizes for both games than the 2nd bin1 files of each game.

Does anyone know if this is a GOG issue? (I hope this is not an issue on my side)

Edit 1: I've attached a pic. You can tell by the timestamp, which is the latest file that worked (the larger one).
.

OK, so are you downloading the offline bins from a browser?

If not, try it.

Download a bin or exe, then grab the download link used. Append .xml onto the end of it and grab that xml file. You'll have to do this before the link dies - 10 minutes or so of inactivity can cause the link to be invalidated.

Inside the xml is a md5 checksum. Use this checksum to verify against the checksum of your downloaded file. If it matches your download is likely the same as what's on the server. If it doesn't match, it's a problem which occurred either on your end, or in transit.

Likely something on your end specifically.
I just finished downloading Shadow of Mordor and Shadow of War (via the Fox) which amounts to about 60 of the 4 GB bin files and they all came through A-OK, passing the integrity check with flying colours.

I've been seeing this as well lately, sometimes files just don't quite complete. I've been trying to remember to check that the download shows complete in the downloads dropdown in Firefox (it doesn't when it is short). I guess the CDN (footprint.net at this point here in the US, which is Lumen aka CenturyLink) drops the connection early at times. My guess was that it somehow times the connection and thinks it should be done earlier than it actually is since I have a fairly slow connection (1.2MB/s actual download speed if not doing anything else), although unless you also have a slow connection it might just be something that randomly closes the connection a bit early. It usually (always?) seems to happen near the end of the file. It seems to happen more when I try to download two larger files at the same time (at half the speed but that way I don't have to remember to start the next one), so I've stopped doing that.

It is really unfortunate that Firefox has no way to resume downloads to finish that last bit of the file instead of needing to download the whole thing again. I've tried some addons that claimed to be able to do that but they haven't worked reliably. I've previously used the cliget addon which makes it possible to resume via curl (you can't resume via the same command line that failed but can get a new link that will resume downloading the same file), however passing cookies on the command line is a potential security issue so I stopped using it. Unfortunately you can't easily give curl the right cookies and then download from the link GOG provides since there are a couple of layers of redirects and curl's --remote-header-name doesn't work through redirects (unless that was added in the last year or two since I tried it).

Desn't sound like a GOG issue.
While a aborted download is nothing out of the ordinary, it should not show as "finished" on your PC.

Luckily the offline installers have an option to test the files before installation.

I don't use a browser to download but the gogrepoc utlity on a Linux server.


GOG does have some problems with download files, meaning that sometimes the description of the file is missing (or gets generated way after the file was uploaded), so the downloader - whatever is used - can only hope that the file was transferred correctly and has no option to test it.

I am unsure what is the actual problem here. Can't you just reload the corrupted file?

It is hard to say whether the issue was on GOG's or your end, or somewhere in between. The fact that the file size was different suggests that the download didn't finish properly for one of the files, and again it is hard to guess which end is responsible for the unfinished download.

I think multipart GOG installers still have the optional integrity check, ie. it will test the installer before actually installing it? Or, if you want to test it yourself before running the installer, I guess you could use innoextract to test the integrity of the installer.

In case you have lots of GOG installers on your hard drive that you want to verify, then I think this is a good tool for that:

https://github.com/Twombs/GOGPlus-Download-Checker

https://www.gog.com/forum/general/gogplus_download_checker/page1

I don't know if this also affects other browsers, but it's been an issue in Firefox for many years. When you see the file size for a file that's downloading -- which is almost always these days -- that means the server sent the browser the exact file size. So the browser shouldn't consider a smaller file complete.

If you're using Windows or a Mac, GOG Galaxy remains the best way to download offline installers, especially if they're large and split into multiple parts.

Actually Firefox CAN resume aborted downloads and it also signals when a download was aborted, depending on the server. And even if the size is unknown, it can detect that the end of stream message is missing and mark the download as aborted.
How's it possible that a file ends up being too small? Don't know. One option would be that the end of the stream was sent too early.

Yes, see the attached screenshot. It's just one click to start downloading all parts of the offline installer, and one more click per DLC and patch. Only one thing is downloaded at a time, so you can queue up multiple items. I haven't noticed any speed difference. I resorted to GOG Galaxy for offline installers out of convenience, since it made it easier to back up many games.

Thanks, I'll probably try that. It seems like a better option than re-downloading a 2nd time.
.

If you decide to give it a go, you'll want to get version 2.0.55.99 and rename the updater executable before launching it. Newer versions have a service executable that crashes constantly.

You're welcome.

In my case under Firefox it does fail, but that is indicated with a tiny yellow triangle that is easy to miss if I'm not looking for it. Possibly something is different in your case but I'm guessing it is just Chrome not showing the error for some reason. I did also once get a .exe with a failed signature check that I'm guessing is the same issue, so I don't think it is strictly .bin files (but seems more likely to happen with larger files). I did a quick search and see mentions that it can sometimes resume when you click retry, I guess that is what you mean? I didn't know that. It doesn't work on GOG, unfortunately, not because the server doesn't support ranges (it does, that is how curl was able to resume and I checked that this is still true on the current CDN) but because it retries the redirected url rather than the url of the link you clicked on and the redirected url no longer works (token expired). It deletes the mostly downloaded file instead, tries to download it again, then fails.

I saw another trick to move the incomplete .part file elsewhere, start the download again, pause it, move the previously downloaded part file back again, then resume. However, it seems pause and resume don't work with GOG either, although I don't know why since in that case it can restart from the beginning and download the full file.

However, I noticed that there are no cookies used for the CDN, just the time limited token (not single use) so it also works to start a download in Firefox, cancel it right away, copy the URL, and use it in curl with --remote-name (doesn't even need --remote-header-name that seems to interfere with resuming a transfer for some reason, however curl doesn't do URL decoding of the name so you also need to use deurlname from renameutils or similar). To resume a partially downloaded file from Firefox on a unixy system (I guess Chrome would be similar but I'm not sure exactly how it works):

1) move <file>.part to a new directory

2) restart the transfer in Firefox, cancel right away, right click on the download and select Copy Download Link

3) in the new directory run: curl -q --tlsv1.2 --proto =https -C - -f --output '<file>.part' '<url>'

4) mv '<file>.part' '<file>'

Something similar should work on Windows (recent Windows even comes with curl, but in PowerShell you need to run it as curl.exe to avoid an unfortunate alias).

Thanks to this thread I also did a check of my already downloaded files and found only one additional issue beyond what I had already noticed, which I think might be a different issue since the file wasn't just short but also had some incorrect content towards the end. At least I think I compared some of the short files and they were just short, although I'll look more carefully if it happens again.

It turns out that innoextract --test doesn't helpfully tell you what file has an issue if you are testing a bunch of them so I used:

fd -g 'setup*.exe' -x echo '{}:' \; -x innoextract --test --gog --silent

And for the linux ones I used the handy xe utility (since somehow there was an extra newline in the middle of the script output when using fd, no idea how that happens :/):

xe -as 'echo -n "$1: "; bash "$1" --check' -- *.sh

Seems like a good habit to test them after downloading.

If you're testing for actual file integrity rather than a download fault, then sure.

Everyone's first stop should be a simple checksum comparison. Sure, GOG doesn't offer .xmls for zip files or some exe extras, but they always intend on having them for the main installers. For the zip archives I run a quick test archive via 7zip. For extra exes which don't have an xml I check the signature. For extra bins which don't have an xml ... I cross my fingers and pray they're whole.

But then again out of all the files I've checksummed over the past two years I haven't had one which was corrupt from GOG.

Yes, that is what I meant.