Primary IERS A table has terminating null and crashing io.ascii parser

This is causing CI failures in this repo and downstream. cc @timj and @adonath

Example log: https://github.com/astropy/astropy/runs/6312385715?check_suite_focus=true

>>> from astropy.utils.data import download_file
>>> from astropy.utils.iers.iers import IERS_Auto
>>> url = 'https://maia.usno.navy.mil/ser7/finals2000A.all'
>>> filename = download_file(url, cache=False)  # Force download of latest copy
>>> t = IERS_Auto.read(file=filename)

.../astropy/utils/iers/iers.py in read(cls, file, readme)
    579             readme = IERS_A_README
    580
--> 581         iers_a = super().read(file, format='cds', readme=readme)
    582
    583         # Combine the A and B data for UT1-UTC and PM columns

.../astropy/table/connect.py in __call__(self, *args, **kwargs)
     60         descriptions = kwargs.pop('descriptions', None)
     61
---> 62         out = self.registry.read(cls, *args, **kwargs)
     63
     64         # For some readers (e.g., ascii.ecsv), the returned `out` class is not

.../astropy/io/registry/core.py in read(self, cls, format, cache, *args, **kwargs)
    210
    211             reader = self.get_reader(format, cls)
--> 212             data = reader(*args, **kwargs)
    213
    214             if not isinstance(data, cls):

.../astropy/io/ascii/connect.py in io_read(format, filename, **kwargs)
     16         format = re.sub(r'^ascii\.', '', format)
     17         kwargs['format'] = format
---> 18     return read(filename, **kwargs)
     19
     20

.../astropy/io/ascii/ui.py in read(table, guess, **kwargs)
    394         else:
    395             reader = get_reader(**new_kwargs)
--> 396             dat = reader.read(table)
    397             _read_trace.append({'kwargs': copy.deepcopy(new_kwargs),
    398                                 'Reader': reader.__class__,

.../astropy/io/ascii/cds.py in read(self, table)
    341                     return table
    342         else:
--> 343             return super().read(table)

.../astropy/io/ascii/core.py in read(self, table)
   1401                                      self.include_names, self.exclude_names)
   1402
-> 1403         table = self.outputter(self.header.cols, self.meta)
   1404         self.cols = self.header.cols
   1405

.../astropy/io/ascii/core.py in __call__(self, cols, meta)
   1137         # Sets col.data to numpy array and col.type to io.ascii Type class (e.g.
   1138         # FloatType) for each col.
-> 1139         self._convert_vals(cols)
   1140
   1141         t_cols = [numpy.ma.MaskedArray(x.data, mask=x.mask)

.../astropy/io/ascii/core.py in _convert_vals(self, cols)
   1080                 # If there are no converters left here then fail.
   1081                 if not col.converters:
-> 1082                     raise ValueError(f'Column {col.name} failed to convert: {last_err}')
   1083
   1084                 converter_func, converter_type = col.converters[0]

ValueError: Column year failed to convert: invalid literal for int() with base 10: '\x00\x00'

[pllim]

I just got a formal reply and turns out the file was corrupted, not just some extra characters. Therefore, I think we can close this issue without further investigation. It seems unrealistic to expect io.ascii to be successful on corrupted data. Below was the reply.

For those still getting error, please make sure you are not using a cached corrupted copy of the file by clearing the cache or force a re-download.

---

Thank you very much for reporting this. I’ve investigated the issue, and it appears that there was some problem with our automated upload process yesterday which caused finals2000A.data to become partially corrupted. Not only did the file end in multiple null characters, as you observed, but several lines of data were missing. I’ve reuploaded the file to … and verified that it is now correct as it appears on the website. It should have the following MD5 checksum: 010e3d39264d65e4c7037c8f135f4440

Thanks again for bringing this to our attention. In the future, you can directly reach the group that publishes these files at our new group email address: eopcp [at] us.navy.mil

[pllim]

Looks like this file has been fixed upstream because I no longer see the error when I download a fresh copy. I am removing the 🔥 label but will keep this issue open for now in case @taldcroft wants to investigate io.ascii parsing, otherwise feel free to close the issue. Thanks, all!