Re: Fetch_NS

In article <6a0bad7659.DaveMeUK@BeagleBoard-xM>,
David Higton <dave@davehigton.me.uk> wrote:
> In message <597697dd4dbrian.jordan9@btinternet.com>
> Brian Jordan <brian.jordan9@btinternet.com> wrote:

> > In article <59767da924dave@triffid.co.uk>,
> > Dave <dave@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-leave@netsurf-browser.org