From Newsgroup: comp.sys.acorn.programmer

Hi there,

Trying to read a log file when the file is already open by the the utility that is create it.(downloading a file using WGet and reading the log file
to display percentage downloaded)

Using SYS "XOS_Find",&4F,file$ TO handle%

Now the above works fine on my RO4.42 and RO5 devices.

When I test with VRPC with RO4 and RO6, Error is generated: Handle is
either illegal or has been closed and errors with the line number the
above SYS command is on.

I'm doing
OS_Find command to open the file
getting the size
OS_GBPB to read into buffer
OS_Find to then close the file.

Above all works fine on 4.42 and 5, but generates the Handle is either
illegal or has been closed error on RO4 and RO6.

Any ideas as to why the RO4 and RO6 do not like SYS "XOS_Find",&4F,file$
TO handle% with a file that is already open and being updated, where as
other OS's are fine with it?
--
Paul Stewart
Sent from A9home running RISC OS 4.42
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In message <b171d8ae5c.Paul@phorefaux>
Paul Stewart <phorefaux@gmail.com> wrote:

Hi there,

Trying to read a log file when the file is already open by the the utility that is create it.(downloading a file using WGet and reading the log file
to display percentage downloaded)

Using SYS "XOS_Find",&4F,file$ TO handle%

Now the above works fine on my RO4.42 and RO5 devices.

When I test with VRPC with RO4 and RO6, Error is generated: Handle is
either illegal or has been closed and errors with the line number the
above SYS command is on.

I'm doing
OS_Find command to open the file
getting the size
OS_GBPB to read into buffer
OS_Find to then close the file.

Above all works fine on 4.42 and 5, but generates the Handle is either illegal or has been closed error on RO4 and RO6.

Any ideas as to why the RO4 and RO6 do not like SYS "XOS_Find",&4F,file$
TO handle% with a file that is already open and being updated, where as
other OS's are fine with it?

Not sure, but osfind must have evolved
According to OSLib's SHelp manual, there are 32bit handles, the old ones
were 8bit. from version 6.3 the handles are 32 bits. I don't know how to distinguish with Sys "OSfind" on Ro4 ?

You can display handle% for comparison. (Reporter is fine!)
--
Jean-Michel
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In article <2b3b10af5c.jmb@jmc.bruck.orange.fr>,
Jean-Michel <jmc.bruck@orange.fr> wrote:

In message <b171d8ae5c.Paul@phorefaux>
Paul Stewart <phorefaux@gmail.com> wrote:

Hi there,

Trying to read a log file when the file is already open by the
the utility that is create it.(downloading a file using WGet and
reading the log file to display percentage downloaded)

Using SYS "XOS_Find",&4F,file$ TO handle%

Now the above works fine on my RO4.42 and RO5 devices.

When I test with VRPC with RO4 and RO6, Error is generated:
Handle is either illegal or has been closed and errors with the
line number the above SYS command is on.

I'm doing
OS_Find command to open the file
getting the size
OS_GBPB to read into buffer
OS_Find to then close the file.

Above all works fine on 4.42 and 5, but generates the Handle is
either illegal or has been closed error on RO4 and RO6.

Any ideas as to why the RO4 and RO6 do not like SYS
"XOS_Find",&4F,file$ TO handle% with a file that is already open
and being updated, where as other OS's are fine with it?

Not sure, but osfind must have evolved According to OSLib's SHelp
manual, there are 32bit handles, the old ones were 8bit. from
version 6.3 the handles are 32 bits. I don't know how to
distinguish with Sys "OSfind" on Ro4 ?

You can display handle% for comparison. (Reporter is fine!)

I suspect the differences are more to do with the FileSystem being
used, rather than the RISC OS version. I have certainly seen
differences in what can be done to open files on different file
systems.
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 22 Feb, Martin wrote in message
<5caf1565f8News04@avisoft.f9.co.uk>:

I suspect the differences are more to do with the FileSystem being used, rather than the RISC OS version. I have certainly seen differences in what can be done to open files on different file systems.

Indeed. Assuming that 4.42 and 5.xx are not running on VRPC, I would
suggest that it's worth checking whether VRPC's HostFS is happy to allow two clients to access the same file at the same time (where HostFS will probably just be passing on what Windows does by default).
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In message <5caf1565f8News04@avisoft.f9.co.uk>
Martin <News04@avisoft.f9.co.uk> wrote:

In article <2b3b10af5c.jmb@jmc.bruck.orange.fr>,
Jean-Michel <jmc.bruck@orange.fr> wrote:

In message <b171d8ae5c.Paul@phorefaux>
Paul Stewart <phorefaux@gmail.com> wrote:

Hi there,

Trying to read a log file when the file is already open by the
the utility that is create it.(downloading a file using WGet and
reading the log file to display percentage downloaded)

Using SYS "XOS_Find",&4F,file$ TO handle%

Now the above works fine on my RO4.42 and RO5 devices.

When I test with VRPC with RO4 and RO6, Error is generated:
Handle is either illegal or has been closed and errors with the
line number the above SYS command is on.

I'm doing
OS_Find command to open the file
getting the size
OS_GBPB to read into buffer
OS_Find to then close the file.

Above all works fine on 4.42 and 5, but generates the Handle is
either illegal or has been closed error on RO4 and RO6.

Any ideas as to why the RO4 and RO6 do not like SYS
"XOS_Find",&4F,file$ TO handle% with a file that is already open
and being updated, where as other OS's are fine with it?

Not sure, but osfind must have evolved According to OSLib's SHelp
manual, there are 32bit handles, the old ones were 8bit. from
version 6.3 the handles are 32 bits. I don't know how to
distinguish with Sys "OSfind" on Ro4 ?

You can display handle% for comparison. (Reporter is fine!)

I suspect the differences are more to do with the FileSystem being
used, rather than the RISC OS version. I have certainly seen
differences in what can be done to open files on different file
systems.

Good shout, that had crossed my mind.
In all cases, the file is being read from Wimp$ScrapDir.
On RO4.39, this is set to Memphis, as is the case on RO4/6 (or so I was thinking, however, now having checked this, I see I was wrong, it was set
to !Scrap folder in Resources on HostFS, if I set to Memphis, works as expected. On further testing. Reading the file works fine with Memphis,
but errors with IDEFS, HOSTS,ADFS(VRPC),SDFS.

Therefore my next question.
I am using webget and outputting the log file to scrap. I am trying to
update a window with percentage of file downloaded, which as I now know
works fine with Memphis, but not anything else :(. The file itself is
open by webget as it is updating it. I also need to open it for reading
so I can get the download percentage.

With OS_Find not working apart from on Memphis, is there another way to do this?
--
Paul Stewart
Sent from A9home running RISC OS 4.42
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 22 Feb 2026 as I do recall,
Paul Stewart wrote:

[snip]

I am using webget and outputting the log file to scrap. I am trying to update a window with percentage of file downloaded, which as I now know works fine with Memphis, but not anything else :(. The file itself is
open by webget as it is updating it. I also need to open it for reading
so I can get the download percentage.

With OS_Find not working apart from on Memphis, is there another way to do this?

What happens if you use OS_File 255 (Load File) instead of OS_Find?
--
Harriet Bazley == Loyaulte me lie ==

Mate, this parrot wouldn't VOOM if you put four million volts through it!
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 22 Feb, Paul Stewart wrote in message
<97283caf5c.Paul@phorefaux>:

Therefore my next question. I am using webget and outputting the log file
to scrap. I am trying to update a window with percentage of file
downloaded, which as I now know works fine with Memphis, but not anything else :(. The file itself is open by webget as it is updating it. I also need to open it for reading so I can get the download percentage.

With OS_Find not working apart from on Memphis, is there another way to do this?

Would using PipeFS solve the problem? That has been in the OS since
RISC OS 3, and is intended to allow for inter-task file transfer.

I've used it in PrintPDF for communicating with TaskWindow-based tasks, but
not in quite this way. I would assume (but haven't checked) that it would
allow reading from a file that something else was writing to, because that feels like a significant part of its purpose.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In message <3a2352af5c.harriet@bazleyfamily.co.uk>
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

On 22 Feb 2026 as I do recall,
Paul Stewart wrote:

[snip]

I am using webget and outputting the log file to scrap. I am trying to
update a window with percentage of file downloaded, which as I now know
works fine with Memphis, but not anything else :(. The file itself is
open by webget as it is updating it. I also need to open it for reading
so I can get the download percentage.

With OS_Find not working apart from on Memphis, is there another way to do >> this?

What happens if you use OS_File 255 (Load File) instead of OS_Find?

Same issue, reports file is aleady open.

I will dig into Steve Fryatt's suggestion of using PipeFS.
Would appear to be a lot of hassle just to display a download percentage,
but would like to indicate how far through the download WGet is. And it's
a learning curve!
--
Paul Stewart
Sent from A9home running RISC OS 4.42
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

On 23 Feb, Paul Stewart wrote in message
<1e8bd4af5c.Paul@phorefaux>:

I will dig into Steve Fryatt's suggestion of using PipeFS. Would appear to
be a lot of hassle just to display a download percentage,

Why is it "a lot of hassle"?

I assume that you're doing something like

wget <stuff> -o <some-temporary-logfile-name>

to generate your logfile. Instead of that, just do

wget <stuff> -o pipe:$.YourAppName

and then try to open that same file using OS_Find. Calling it "YourAppName" (where that's the actual name that you've registered with ROOL for the application) is a way to minimise the risk that someone else will also be trying to use the same filename at the same time.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In message <mpro.tavube00gpoog1f85.news@stevefryatt.org.uk>
Steve Fryatt <news@stevefryatt.org.uk> wrote:

On 22 Feb, Paul Stewart wrote in message
<97283caf5c.Paul@phorefaux>:

Therefore my next question. I am using webget and outputting the log file
to scrap. I am trying to update a window with percentage of file
downloaded, which as I now know works fine with Memphis, but not anything
else :(. The file itself is open by webget as it is updating it. I also
need to open it for reading so I can get the download percentage.

With OS_Find not working apart from on Memphis, is there another way to do >> this?

Would using PipeFS solve the problem? That has been in the OS since
RISC OS 3, and is intended to allow for inter-task file transfer.

I've used it in PrintPDF for communicating with TaskWindow-based tasks, but not in quite this way. I would assume (but haven't checked) that it would allow reading from a file that something else was writing to, because that feels like a significant part of its purpose.

Run into same issue with PipeFS, with added bonus if it blocking when pipe gets full. Everyday is a learning day :)
--
Paul Stewart
Sent from A9home running RISC OS 4.42
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.sys.acorn.programmer

In message <mpro.taxlnn00tiska0e9q.news@stevefryatt.org.uk>
Steve Fryatt <news@stevefryatt.org.uk> wrote:

I will dig into Steve Fryatt's suggestion of using PipeFS. Would appear to >> be a lot of hassle just to display a download percentage,

Why is it "a lot of hassle"?

Poor choice of words on my part.
--
Paul Stewart
Sent from A9home running RISC OS 4.42
--- Synchronet 3.21d-Linux NewsLink 1.2