Don't overwrite TGList_BM.txt without first checking if update successful

Suggest new features here
Post Reply
ke8dpf
Posts: 11
Joined: Fri Jun 29, 2018 10:43 pm

Don't overwrite TGList_BM.txt without first checking if update successful

Post by ke8dpf »

One of the files that pi-star updates is /usr/local/etc/TGList_BM.txt. However, when BM doesn't respond for whatever reason, pi-star overwrites the current TGList_BM.txt file with a stub containing only the error message "Unable to communicate with the BrandMeister API :(".

It would be better if the update were downloaded to a tempfile, and then moved into place as TGList_BM.txt only after it is determined that the update is any good. If the download failed for any reason, this would at least preserve the data in that file. As it is, if the download fails, not only do you not get the new version, but you've blown out the old version as well.
ke8dpf
Posts: 11
Joined: Fri Jun 29, 2018 10:43 pm

Re: Don't overwrite TGList_BM.txt without first checking if update successful

Post by ke8dpf »

KE7FNS wrote: Sun Jun 20, 2021 6:38 am The hostfiles are not coming from BM, they are coming from Andys pistar.uk server.

The pistar.uk server should always contain a full list, so apparently there is a problem with the server talking to BM. Andy will get it sorted, then everything will fall into line automatically.
I understand that the file is coming from Andy's server, and I understand that he's aware of the API failures. I also understand that the errors might be transient, could vary in cause each time, and that Andy may not "get it sorted", if the problem is on the BM end or otherwise not under his control.

My point is, that there's little sense in propagating such a failure to every pi-star user, when a file is bad. Either the pistar.uk server should not make the empty "updated" file available for everyone's hotspots to inherit, or the HostFilesUpdate.sh script should not blindly overwrite a target file with a note that basically says "Hey, Andy's server got some error from BM, so we're going to blow out your TGList anyway."
User avatar
MW0MWZ
Site Admin
Posts: 1505
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: Don't overwrite TGList_BM.txt without first checking if update successful

Post by MW0MWZ »

ke8dpf wrote: Sun Jun 20, 2021 8:45 am My point is, that there's little sense in propagating such a failure to every pi-star user, when a file is bad. Either the pistar.uk server should not make the empty "updated" file available for everyone's hotspots to inherit, or the HostFilesUpdate.sh script should not blindly overwrite a target file with a note that basically says "Hey, Andy's server got some error from BM, so we're going to blow out your TGList anyway."
I agree, and I had thought that I have a check for that (I do for the other files that I update...) I'll double check what is up with this one, KE7FNS told me about it, and of course by the time I check - it was fine... but it should be robust - I'll come back when I have an answer...
Andy

73 de MW0MWZ
http://pistar.uk
User avatar
MW0MWZ
Site Admin
Posts: 1505
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: Don't overwrite TGList_BM.txt without first checking if update successful

Post by MW0MWZ »

Found (now fixed) a pretty good typo in the check... I was checking that the output file was larger than 16 chars, and not 16 lines... well yeah.
Now fixed, should not happen again.
Andy

73 de MW0MWZ
http://pistar.uk
ke8dpf
Posts: 11
Joined: Fri Jun 29, 2018 10:43 pm

Re: Don't overwrite TGList_BM.txt without first checking if update successful

Post by ke8dpf »

MW0MWZ wrote: Sun Jun 20, 2021 3:52 pm Found (now fixed) a pretty good typo in the check... I was checking that the output file was larger than 16 chars, and not 16 lines... well yeah.
Now fixed, should not happen again.
Sweet. Thanks. Yeah, I had noticed the problem last night, when the contents of TGList_BM.txt was replaced with "Unable to communicate with the BrandMeister API". I had written a script for the HDMI console/SSH that watches DMR traffic. That script draws from that file, in order to display the TG's name along with the rest of the relevant data about the QSO in progress. When I noticed the TG name was blank on my screen, I'd first thought I'd introduced a bug in my script, and then I noticed the above error in the TGList_BM.txt file.

Anyway, thanks for getting to that.

Ken
Post Reply