In article <6a0bad7659.DaveMeUK@BeagleBoard-xM>, David Higton <d...@davehigton.me.uk> wrote: > In message <597697dd4dbrian.jord...@btinternet.com> > Brian Jordan <brian.jord...@btinternet.com> wrote:
> > In article <59767da924d...@triffid.co.uk>, > > Dave <d...@triffid.co.uk> 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
