Re: Fetch_NS
In message <5976cc379ed...@triffid.co.uk> Dave wrote: > In article <62f3ba7659.DaveMeUK@BeagleBoard-xM>, > David Higton 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. Perhaps you can do one more confirmatory check, at least on the 6.20 system, but on as many systems as you like. Just run this: *Filer_Run InetDBase:CertData The result ought to be simply that the CertData file is opened up in a text editor. If that works, then AcornSSL, curl, future versions of NetSurf, and who knows what else, will find the CertData file in the right place. If that /doesn't/ happen on one or more of your systems, we have a problem. > I do know of two others but they are in the "Backup" directory... We don't need to bother about them, fortunately. David ___ netsurf-users mailing list -- netsurf-users@netsurf-browser.org To unsubscribe send an email to netsurf-users-le...@netsurf-browser.org
Re: Fetch_NS
In article <62f3ba7659.DaveMeUK@BeagleBoard-xM>, David Higton 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... Dave -- Dave Triffid ___ netsurf-users mailing list -- netsurf-users@netsurf-browser.org To unsubscribe send an email to netsurf-users-le...@netsurf-browser.org
Re: Fetch_NS
In message <5976b50516netsurf-users-...@aconet.nl> Frank de Bruijn wrote: > 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. The most remarkable thing happened earlier this afternoon. I had started to think along the lines of finding a InetDBase:CertData file and canonicalising the path. I opened PRMv2 in the area that I know to hold the information about filing system operations, and it fell open at OS_FSControl 37! I had a play and, as you did long before me, found it to do what I want. Except there's still a snag... The scheme is: InetDBase$Write exists and is valid -> use it. InetDBase$Write exists and is invalid -> canonicalise path to existent CertData file. InetDBase$Write doesn't exist -> use InetDBase: 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 ___ netsurf-users mailing list -- netsurf-users@netsurf-browser.org To unsubscribe send an email to netsurf-users-le...@netsurf-browser.org
Re: Fetch_NS
In article <6a0bad7659.DaveMeUK@BeagleBoard-xM>, David Higton wrote: > In message <597697dd4dbrian.jord...@btinternet.com> > Brian Jordan wrote: > > In article <59767da924d...@triffid.co.uk>, > > Dave 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. > There's a worrying aspect to this. RISC OS 5 returns InetDBase: as a > writable path (no multiple choices within it). RISC OS 4.39 and 6.20 > don't. OK, there ought to be an alternative approach: check to see if > InetDBase$Write exists; if yes, use it, else use InetDBase:. But that > will only work if InetDBase$Write is a valid path, and 2 out of 2 users > of 6.20 so far have shown that it isn't. > Even a test for validity is problematic, because AFAICS the fallback > from there is to use a fixed path. > I'm looking for helpful ideas here. 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. > Among which, does anyone have any idea why InetDBase$Write is invalid > on 6.20? Presumably if we could find out why, we could fix it. No idea. Regards, Frank ___ netsurf-users mailing list -- netsurf-users@netsurf-browser.org To unsubscribe send an email to netsurf-users-le...@netsurf-browser.org
Re: Fetch_NS
In article <59767da924d...@triffid.co.uk>, Dave 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. > Obviously I have no idea what it all means... RISC OS 6.20 hasn't been > touched/updated since December 2009. And a MeToo here. The rest of this thread has enabled me to get Fetch_NS going again although there doesn't seem to be a great deal new for me to fetch... B -- _ Brian Jordan RISC OS 5.28 (19-Oct-20) on Raspberry Pi _ ___ netsurf-users mailing list -- netsurf-users@netsurf-browser.org To unsubscribe send an email to netsurf-users-le...@netsurf-browser.org
Re: Fetch_NS
In message <597697dd4dbrian.jord...@btinternet.com> Brian Jordan wrote: > In article <59767da924d...@triffid.co.uk>, > Dave 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. There's a worrying aspect to this. RISC OS 5 returns InetDBase: as a writable path (no multiple choices within it). RISC OS 4.39 and 6.20 don't. OK, there ought to be an alternative approach: check to see if InetDBase$Write exists; if yes, use it, else use InetDBase:. But that will only work if InetDBase$Write is a valid path, and 2 out of 2 users of 6.20 so far have shown that it isn't. Even a test for validity is problematic, because AFAICS the fallback from there is to use a fixed path. I'm looking for helpful ideas here. Among which, does anyone have any idea why InetDBase$Write is invalid on 6.20? Presumably if we could find out why, we could fix it. David ___ netsurf-users mailing list -- netsurf-users@netsurf-browser.org To unsubscribe send an email to netsurf-users-le...@netsurf-browser.org
