PDS files in subscriptions now in both bz2 and 'data' format
Posted: Wed May 13, 2020 12:08 pm America/New_York
Sean,
There seems to be an issue which began on May 6th. It is happening in at least 21 of my subscriptions. Here is the result of a query just performed:
[bmurch@dell8 ~]$ curl --retry 5 --retry-delay 2 -d "subID=1843&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search
MOD00.P2020131.1145_1.PDS.bz2
MOD00.P2020131.1320_1.PDS.bz2
MOD00.P2020131.1325_1.PDS.bz2
MOD00.P2020132.1220_1.PDS.bz2
MOD00.P2020132.1225_1.PDS.bz2
MOD00.P2020132.1400_1.PDS.bz2
MOD00.P2020132.1405_1.PDS.bz2
MOD00.P2020133.1305_1.PDS.bz2
MOD00.P2020133.1310_1.PDS.bz2
MOD00.P2020134.1210_1.PDS
MOD00.P2020134.1215_1.PDS.bz2
MOD00.P2020134.1350_1.PDS
MOD00.P2020134.1355_1.PDS
Notice that three are that are not bz2 files and downloaded as data.
[bmurch@optics0 S4P_MODIS_H5]$ ll /cms_zfs/sat_data/modis/l0/bad/MOD00.P2020134.1210_1.PDS
-rw-rw-r-- 1 bmurch cms_optics 395148432 May 13 10:28 /cms_zfs/sat_data/modis/l0/bad/MOD00.P2020134.1210_1.PDS
[bmurch@optics0 S4P_MODIS_H5]$ file /cms_zfs/sat_data/modis/l0/bad/MOD00.P2020134.1210_1.PDS
/cms_zfs/sat_data/modis/l0/bad/MOD00.P2020134.1210_1.PDS: data
I have a program that has been running for at least 8 years, and this is the first time this has ever happened.
My program determines the appropriate name of a workorder from the granule, and where to plavce it, based on a name like this:
# determine the actual wo name:
$wo_name_h5 =~ s/(.*)\.PDS\.bz2/PRI1.DO.SEADAS_L1A_GEO_EXTRACT_H5\.$site_key\.$sat_key\.$1\.wo/;
In some cases, these are grabbed as "HTML" file errors.
This causes great problems with several scripts, both in the initial download and where to put it, to the scripts that bunzip2 the files.
In some cases, the files are later "fixed" by NASA and downloaded again as bz2 files in which case my scripts work.
It was a fluke that I found this at all as the errors are totally random, independent of time or day.
Please advise. If this is going to be a continuing problem, I will have a major rewrite to do.
Brock
There seems to be an issue which began on May 6th. It is happening in at least 21 of my subscriptions. Here is the result of a query just performed:
[bmurch@dell8 ~]$ curl --retry 5 --retry-delay 2 -d "subID=1843&results_as_file=1" https://oceandata.sci.gsfc.nasa.gov/api/file_search
MOD00.P2020131.1145_1.PDS.bz2
MOD00.P2020131.1320_1.PDS.bz2
MOD00.P2020131.1325_1.PDS.bz2
MOD00.P2020132.1220_1.PDS.bz2
MOD00.P2020132.1225_1.PDS.bz2
MOD00.P2020132.1400_1.PDS.bz2
MOD00.P2020132.1405_1.PDS.bz2
MOD00.P2020133.1305_1.PDS.bz2
MOD00.P2020133.1310_1.PDS.bz2
MOD00.P2020134.1210_1.PDS
MOD00.P2020134.1215_1.PDS.bz2
MOD00.P2020134.1350_1.PDS
MOD00.P2020134.1355_1.PDS
Notice that three are that are not bz2 files and downloaded as data.
[bmurch@optics0 S4P_MODIS_H5]$ ll /cms_zfs/sat_data/modis/l0/bad/MOD00.P2020134.1210_1.PDS
-rw-rw-r-- 1 bmurch cms_optics 395148432 May 13 10:28 /cms_zfs/sat_data/modis/l0/bad/MOD00.P2020134.1210_1.PDS
[bmurch@optics0 S4P_MODIS_H5]$ file /cms_zfs/sat_data/modis/l0/bad/MOD00.P2020134.1210_1.PDS
/cms_zfs/sat_data/modis/l0/bad/MOD00.P2020134.1210_1.PDS: data
I have a program that has been running for at least 8 years, and this is the first time this has ever happened.
My program determines the appropriate name of a workorder from the granule, and where to plavce it, based on a name like this:
# determine the actual wo name:
$wo_name_h5 =~ s/(.*)\.PDS\.bz2/PRI1.DO.SEADAS_L1A_GEO_EXTRACT_H5\.$site_key\.$sat_key\.$1\.wo/;
In some cases, these are grabbed as "HTML" file errors.
This causes great problems with several scripts, both in the initial download and where to put it, to the scripts that bunzip2 the files.
In some cases, the files are later "fixed" by NASA and downloaded again as bz2 files in which case my scripts work.
It was a fluke that I found this at all as the errors are totally random, independent of time or day.
Please advise. If this is going to be a continuing problem, I will have a major rewrite to do.
Brock