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?
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.
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.
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?
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?
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?
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,
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.
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"?
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 121:40:46 |
| Calls: | 125 |
| Calls today: | 125 |
| Files: | 489 |
| D/L today: |
859 files (365M bytes) |
| Messages: | 76,646 |
| Posted today: | 26 |