Hello,
this is the problem
AI-generated summary
The discussion revolves around an error encountered while restoring a backup. pfaffman initially suspects a corrupted backup file. Ed_S suggests the problem might be due to the backup file being uncompressed when downloaded, making it unsuitable for restoration. Ed_S provides a set of commands to check the backup file:
ls -l filename
file filename
gunzip -tv filename
tar tfz filename
pfaffman agrees that the issue might be caused by some browsers and/or OSes automatically uncompressing files upon download, making it difficult to detect changes. Ed_S proposes implementing a GUI recovery method that checks the backup file and reports any errors, including file size and type. inj3ct0r agrees with pfaffman’s point about Windows hiding file extensions by default.
My guess is a corrupted backup file.
Seems likely. But just possibly the problem is that the backup file has already been uncompressed - perhaps uncompressed when downloaded - and so is not in good shape for the restore.
Check the backup file with
ls -l filename
file filename
gunzip -tv filename
tar tfz filename
That seems like the most likey lway that the backup could have been corrupted (given that it was uploaded and not in the same place where it was created). It seems that some browsers and/or OSes “helpfully” uncompress things immediately on download, or otherwise make it hard to tell that it’s been changed.
I think Windows makes it exceptionally hard to tell if that has happened, as it explicitly hides extensions by default.
If you’re using an OS where someone is likely to use those commands, it’s probably unlikely that it’s caused the problem. 
Yes, I was supposing a person was logged into their Discourse instance.
If we offer a GUI method to recover a backup, for people unfamiliar with the command line, perhaps that code can include some check on the backup file and at least report the size and type if the uncompression library throws an error.
I agree with you