Alright, I dug into this and actually figured what was going on. TL;DR: larsoner is right, one of the files was corrupted, redownloading solved the problem.
I fell back through the traceback and set up debug messages here and there trying to catch something. Long story short, it turned out that fsaverage-5120-5120-5120-bem-sol.fif was incomplete, so the solution matrix could not be loaded. What still bothered me a little bit, though, was that the files are meant to be checked by their hashes, so I decided to explore this a bit more. The hash sum of a temporary zip-file is checked after the file is downloaded (pooch/core.py, stream_download function, which, in turn, are called from MNE’s datasets/utils.py, _manifest_check_download function):
with temporary_file(path=str(fname.parent)) as tmp:
downloader(url, tmp, pooch)
hash_matches(tmp, known_hash, strict=True, source=str(fname.name))
This works just fine: if the downloaded file is good then nothing happens, otherwise hash_matches raises ValueError indicating a mismatch. I didn’t get any errors of this kind, but for good measure I compared the hashes of correct and corrupted files - because things happen and md5-hash collision is theoretically possible. Indeed, the hashes were different (and this is the fact I’m really glad of, because otherwise I would have officially manifested myself as the unluckiest person the history has ever seen).
Well, it works just fine unless something really weird happens. I’m not really sure what exactly went wrong, but I have two options: it was either the previous version of MNE’s fetch_average (first time I did it at 1.0.0, faced problems and updated to 1.2.2; 1.0.0 actually did raise the hash mismatch error and might have left the inconsistent data) or my hard drive that suddenly ran out of free space in the middle of the downloading process and caused hash_matches to not be called. Either way, the zip-file was corrupted but actually got unpacked. Actually, MNE itself has one more check (the first check, actually, datasets/utils.py, _manifest_check_download function):
with open(manifest_path, 'r') as fid:
names = [name.strip() for name in fid.readlines()]
manifest_path = op.basename(manifest_path)
need = list()
for name in names:
if not op.isfile(op.join(destination, name)):
need.append(name)
logger.info('%d file%s missing from %s in %s'
% (len(need), _pl(need), manifest_path, destination))
if len(need) > 0:
with tempfile.TemporaryDirectory() as path:
logger.info('Downloading missing files remotely')
fname_path = op.join(path, 'temp.zip')
pooch.retrieve(
url=url,
known_hash=f"md5:{hash_}",
path=path,
fname=op.basename(fname_path)
)
That is, it retrieves a list of needed files from a manifest file, and if something is missing, the downloading process starts. Unfortunately, it was not my case as no file was actually lacking, just one of them was incomplete (but presented still).
At the end of day, I’m not really sure what I should do now. On the one hand, it looks like a bug. Furthermore, it can easily be fixed by checking not only hash of a zip-file, but also hashes of the unpacked files instead of just their existence. On the other hand, it feels pretty much like a unique situation, and I highly doubt it will ever happen once again. Any suggestions?