Re: Fetch_NS

In message <5976b50516netsurf-users-sub@aconet.nl>
Frank de Bruijn <netsurf-users-sub@aconet.nl> 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-leave@netsurf-browser.org