Unable to open regular file when it has an extension indicating it's compressed

Description

If a FITS file has an extension that indicates it’s a compressed file, but it’s not actually compressed, Astropy can’t open the file. This is because in line 441 of https://github.com/astropy/astropy/blob/main/astropy/io/fits/file.py, Astropy determines file type based on the extension, so if the file has .gz at the end of it, it’ll get uncompressed regardless of whether it’s actually compressed or not.

Expected behavior

I would expect AstroPy to be able to understand that the file isn’t actually compressed, and be able to open the file.

Actual behavior

I get the following error:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/edbraun/opt/anaconda3/lib/python3.8/site-packages/astropy/io/fits/hdu/hdulist.py", line 173, in fitsopen
    return HDUList.fromfile(name, mode, memmap, save_backup, cache,
  File "/Users/edbraun/opt/anaconda3/lib/python3.8/site-packages/astropy/io/fits/hdu/hdulist.py", line 408, in fromfile
    return cls._readfrom(fileobj=fileobj, mode=mode, memmap=memmap,
  File "/Users/edbraun/opt/anaconda3/lib/python3.8/site-packages/astropy/io/fits/hdu/hdulist.py", line 1113, in _readfrom
    raise OSError('Empty or corrupt FITS file')
OSError: Empty or corrupt FITS file

Steps to Reproduce

1. Take a regular FITS file (example.fits) and rename it to add a .gz extension (example.fits.gz). DO NOT actually compress the file.
2. Try to open the file in AstroPy, e.g., with the following script:

from astropy.io import fits
hdu = fits.open('example.fits.gz')

System Details

macOS-10.15.7-x86_64-i386-64bit Python 3.8.5 (default, Sep 4 2020, 02:22:02) [Clang 10.0.0 ] Numpy 1.19.4 astropy 4.3.dev1522+gbb4c1973f Scipy 1.5.2 Matplotlib 3.3.2

[embray]

Oh, I think I remember why the extension checks are there. They are used for writing: If you write a new FITS file (or update an existing one) that has common compression extensions it will write it compressed.

So any fix for this needs to account for the mode argument and ensure that on write mode it will open the file with the correct compression wrapper. But for reading/updating an existing file it could rely on the magic number alone.

[pllim]

OK, thanks for the clarifications!