Hi all, I used to use Fetch_NS daily. Recently it has stopped working, complaining of an incorrectly formatted filename - of course it's incorrectly formatted because it's the empty string. The error is coming from Fetch_NS.Resources.SetLatest. I'm trying to analyse why it isn't working, but the code is crunched, or very nearly so, which means I'm struggling to understand it. Has it stopped working for anyone else? If so, do you have a solution?

In article <ddfac27559.DaveMeUK@BeagleBoard-xM>, David Higton <dave(a)davehigton.me.uk&gt; wrote: > In message <6160be7559.DaveMeUK@BeagleBoard-xM> > David Higton <dave(a)davehigton.me.uk&gt; wrote: > >Hi all, > > I used to use Fetch_NS daily. Recently it has stopped working, > >complaining of an incorrectly formatted filename - of course it's > >incorrectly formatted because it's the empty string. The error is > >coming from Fetch_NS.Resources.SetLatest. > > > >I'm trying to analyse why it isn't working, but the code is crunched, or > >very nearly so, which means I'm struggling to understand it. > > > >Has it stopped working for anyone else? If so, do you have a solution? > Following up my own post: it looks like my CertData file must have > contained an invalid certificate (even though it was only 3 months out > of data), because replacing that has fixed the problem. > I have updated a couple of lines in !Boot.Choices.Fetch_NS.Settings. > These are the new ones: > Set Fetch_NS$Url https://ci.netsurf-browser.org/builds/riscos/ > Set Fetch_NS$Opt --ca-certificate=InetDbase:CertData -qO > First one is to use https rather than http. Second one is to use the > central InetDbase:CertData file rather than a separate (and non- > maintained) copy. > David Ooeer! slight aside but similar problem... I've not updated Netsurf recently so prompted by the above notes thought I better do it. Error from Fetch_NS Error : &00000000 Message: file LATEST missing or empty at line 6 I have no idea what that is, or where it originates from... Any ideas please how to fix whatever it is?

I have made the changes, but the error is the same. The full error message courtesy of Reporter is: ** WimpError ** from unknown task Error : &00000000 Message: file LATEST missing or empty at line 6

In message <5975ccea71dave(a)triffid.co.uk&gt; Dave <dave(a)triffid.co.uk&gt; wrote:

>I have made the changes, but the error is the same. > >The full error message courtesy of Reporter is: > >** WimpError ** from unknown task > Error : &00000000 > Message: file LATEST missing or empty at line 6

OK, open the InetDbase:CertData file and tell us the date you'll see near the top (it's the 4th line in mine).

Mine says:

## Certificate data from Mozilla as of: Thu Sep 30 03:12:05 2021 GMT

David

In article <59760173fadave(a)triffid.co.uk&gt;, Dave <dave(a)triffid.co.uk&gt; wrote: > In article <a24acd7559.DaveMeUK@BeagleBoard-xM>, > David Higton <dave(a)davehigton.me.uk&gt; wrote: > [Snip] > > OK, open the InetDbase:CertData file and tell us the date you'll see > > near the top (it's the 4th line in mine). > > Mine says: > > ## Certificate data from Mozilla as of: Thu Sep 30 03:12:05 2021 GMT > > David > Thanks for the advice David. :-) > Mine is/was: > Certificate data from Mozilla as of: Wed Jan 1 04:12:10 2020 GMT > I downloaded and tried your updater, but unfortunately it errored out. > !Reporter" > ---------- > [WindowManager/] %Obey HostFS::HardDisc4.$.Apps.!UpdCaCert.!Run > No writeable memory at this address > ** Error ** > Error : &00000411 > Maybe something to do with... I'm on RISC OS 6.20 > Thereafter... > Downloaded the cacert.pem and did as you noted in your follow up posting. > So I now have the new CertData in place... > Certificate data from Mozilla as of: Thu Sep 30 03:12:05 2021 GMT. > Rebooted RISC OS... > Tried to run "Fetch_NS and still the same error message... > ** WimpError ** from unknown task > Error : &00000000 > Message: file LATEST missing or empty at line 6 > What next he cried? > Had a lightbulb... :-/ > RISC OS 6.20 has an !Internet.Files.CertData in > ...HardDisc4.$.!Boot.Resources.!Internet.files.CertData > But it also has a > ...HardDisc4.$.!Boot.Choices.Default.Internet.Files.CertData > I replaced that one as well, thereafter, Fetch_NS downloaded the 5313/zip > okay. > Again. > Thanks for the advice, appreciated. > Dave > Apologies for vanishing mid chat last night. (Medical reasons). > D. Me being interested to know... Just tested on this RISC OS 6.20 the CertData really needs to be in ...HardDisc4.$.!Boot.Choices.Default.Internet.Files for Fetch_Netsurf to work. Here on RISC OS 6.20 the CertData in ...HardDisc4.$.!Boot.Resources.!Internet.Files.CertData when renamed out, has no effect on the Fetch_Netsurf running. That said, I'm renaming it back in case something else RISC OS looks for it there. Messy! Had the same Fetch_Netsurf line 6 problem in RPCEmu RISC OS 5.28 install, updated the CertData and it again ran okay. On this 5.28 RISC OS CertData is only in !Boot.Resources.!Internet.Files

As for renaming CertData in other places... Aside from Fetch_NS I have no idea what other apps might use CertData.

In message <59764abf16dave(a)triffid.co.uk&gt; Dave <dave(a)triffid.co.uk&gt; wrote:

> RO 6.20 > -------- > *show inetdbase* > > InetDBase$Path : Choices:Internet.Files. > InetDBase$Write : .Internet.Files

Really? That second path there is invalid.

David

In article <59767da924dave(a)triffid.co.uk&gt;, Dave <dave(a)triffid.co.uk&gt; wrote: [Snip] > Ooeer! > I've just rechecked and that's what is presented after a *show > inetdbase*. I have just had a look at VA here and I get precisely this response to the same input.

In my Updater application (which I couldn't develop further for lack of time... :( ) I canonicalise the path (OS_FSControl 37), which uses the first element of a multiple element path variable. At least it does that on RISC OS 4.39. Here, doing it with InetDBase:CertData results in HostFS::HostFS.$.!Boot.Choices.Users.Single.Internet.Files.CertData Yes, I know, I should use InetDBase$Write. I picked InetDBase because InetDBase$Write looked weird/broken when I (briefly) checked RO 6.

In article <62f3ba7659.DaveMeUK@BeagleBoard-xM>, David Higton <dave(a)davehigton.me.uk&gt; wrote: [Snippy] > The snag is that, as Dave Triffid has told us, more than one CertData > file may exist, possibly in the multiple-choices path. So an updater may > update /a/ CertData file, but not necessarily /the/ /correct/ one. I > don't know how to solve that. > My thinking is one stage on, anyway. There's no point in putting the > path in the !Run file, as it's standard, and is baked into AcornSSL, > curl, and who knows what else. Anywhere else is open to failure by > either updating something other than the standard CertData file, or not > updating anything. > David This has become an interesting thread... :-)

I thought I'd have a check on my 6.20 and see how many CertData files I could find... Eventually I just found the two previously noted ones. ...!Boot.Choices.Default.Internet.Files.CertData (The one in use). And ...!Boot.Resources.!Internet.files.CertData (This one I've named out, and so far no apps have complained or fallen over).

I do know of two others but they are in the "Backup" directory...

In article <cde2d47659.DaveMeUK@BeagleBoard-xM>, David Higton <dave(a)davehigton.me.uk&gt; wrote: > In message <5976cc379edave(a)triffid.co.uk&gt; Dave <dave(a)triffid.co.uk&gt; > wrote:

> > In article <62f3ba7659.DaveMeUK@BeagleBoard-xM>, David Higton > > <dave(a)davehigton.me.uk&gt; wrote: [Snippy] > > > > > The snag is that, as Dave Triffid has told us, more than one > > > CertData file may exist, possibly in the multiple-choices path. > > > So an updater may update /a/ CertData file, but not necessarily > > > /the/ /correct/ one. I don't know how to solve that. > > > > > My thinking is one stage on, anyway. There's no point in putting > > > the path in the !Run file, as it's standard, and is baked into > > > AcornSSL, curl, and who knows what else. Anywhere else is open > > > to failure by either updating something other than the standard > > > CertData file, or not updating anything. > > > > > David > > > > This has become an interesting thread... :-)

> It has, hasn't it? I'm quite enjoying this! :-)

> > I thought I'd have a check on my 6.20 and see how many CertData > > files I could find... > > > > Eventually I just found the two previously noted ones. > > > > ...!Boot.Choices.Default.Internet.Files.CertData (The one in use). > > And ...!Boot.Resources.!Internet.files.CertData (This one I've > > named out, and so far no apps have complained or fallen over).

> Interesting. That's the correct place for it in RISC OS 5, but > apparently not in earlier versions.

Indeed, I've checked on my RPCEmu RISC OS 5.28 install.

In article <ddfac27559.DaveMeUK@BeagleBoard-xM>, David Higton <dave(a)davehigton.me.uk&gt; wrote: > Following up my own post: it looks like my CertData file must have > contained an invalid certificate (even though it was only 3 months out of > data), because replacing that has fixed the problem. > I have updated a couple of lines in !Boot.Choices.Fetch_NS.Settings. > These are the new ones: > Set Fetch_NS$Url https://ci.netsurf-browser.org/builds/riscos/ > Set Fetch_NS$Opt --ca-certificate=InetDbase:CertData -qO > First one is to use https rather than http. Second one is to use the > central InetDbase:CertData file rather than a separate (and non- > maintained) copy. > David Ooeer! slight aside but similar problem... I've not updated Netsurf recently so prompted by the above notes thought I better do it. Error from Fetch_NS Error : &00000000 Message: file LATEST missing or empty at line 6 I have no idea what that is, or where it originates from... Any ideas please how to fix whatever it is?