Closing all open files

Until then my software now has OSCLI("*-ram-close") at the end.

Why not keep track of the files that you’ve opened, and close them all in a standard error handler? BASIC programs are far easier to debug if you have an error handler from the start, because things then exit cleanly.

In general, unless you’re dealing with lots of open files¹, then initialising your file handles to zero at the start of the program before hooking up the error handler

Fh1% = 0 : Fh2% = 0
ON ERROR PROCerror : END

and then cleanly closing files on exit with something like

DEF PROCerror
IF Fh1% <> 0 THEN CLOSE#Fh1% : Fh1% = 0
IF Fh2% <> 0 THEN CLOSE#Fh2% : Fh2% = 0
ENDPROC

is much better than blatting all open files on a filesystem, for the reasons that Rick and Druck have already outlined.

You do need to be careful to always zero your file handles after a CLOSE# command like this

Fh1% = OPENIN(filename$)
IF Fh1% <> 0 THEN
  REM Do stuff with my first file handle.
  CLOSE#Fh1% : Fh1% = 0
ENDIF

but if you’re doing this a lot then you’d quickly wrap it all up into a set of standard library procedures and functions.

¹ ETA: By this I mean that if you’re handling a lot of files you would very quickly end up writing a generalised library to track all of this, storing the handles in a global array as files are opened and zeroing them out again on close. Then on an error, your handler can quickly traverse the array and CLOSE# any non-zero file handles that it finds therein. Exactly how this would be implemented would depend on how you were using the files.

All good stuff, which I already try to do.

Thinking more about it, I have commented out the OSCLI("*-ram-close") close at the end of the program. I want to know which files are left open, if any.

I will use the *-ram-close manually if needed.

Once again, thanks for your help.

By the way, I do not, intentionally, leave files open over a wimp poll.

There is no problem whatsoever in keeping any number of files open over as many Wimp polls as you want.

You might want to check out !resrec by A.J. Pullan. It allows you (anong other things) to see all open files, and selectively close them. Very useful when debugging, and after alt-break.

Here’s my BASIC handler (which requires !Reporter to be available):

DEF PROCclosefile(RETURN H%)
  IF H%=0 THEN ENDPROC
  LOCAL ERROR
    ON ERROR LOCAL PROCcloseerror:ENDPROC
  CLOSE#H%
  RESTORE ERROR
  H%=0
ENDPROC
DEF PROCcloseerror
  *REPORTERROR
 REM PROCwarn("Error closing file: H%="+STR$(H%) + ": " + REPORT$)
  H%=0:
ENDPROC

There is no problem whatsoever in keeping any number of files open over as many Wimp polls as you want.

Technically, there is no problem. But by using polling as a yardstick, it forces one to think more about file access rather than opening a file and leaving it open for an undefined length of time, because that is where the problem lies.

Better, I feel, to open-do_stuff-close as necessary.

Better, I feel, to open-do_stuff-close as necessary.

As always, it depends on what you’re doing. But if you keep opening and closing a file many times, it will be slower than just reading or writing a chunk at a time. Especially for writing, it will be much slower – and it will thrash the storage medium more.

When I say slower, it will also have some impact on other tasks when multi-tasking.

I discovered many years ago that the fastest way to handle files is to read them or write them a chunk at a time, preferably an integral number of sectors of the storage medium. Nowadays I tend to use 64 kiB chunks. That’s what enables my DBack and DRest apps to go so fast, for example.

If you want to know what files are open, use this BASIC program.

REM >FilesOpen
REM Lists open files
:
ON ERROR: ON ERROR OFF: PRINT REPORT$;" at ";ERL:END
:
buflen%=256
DIM buffer% buflen%
:
C%=0
FOR R%=1 TO 255
  SYS "XOS_Args",7,R%,buffer%,,,buflen% TO ;V%
  IF(V% AND 1)=0 THEN
    PRINTRIGHT$("   "+STR$R%,3);" ";
    SYS "OS_Write0",buffer%
    PRINT
    C%+=1
  ENDIF
NEXT
IFC%=0 PRINT"No files open"
END

That works: I can see my open RAM:: files.

Why is SDFS::Pi4.$ described as an open file?

Why is SDFS::Pi4.$ described as an open file?

That only happens if an unpartioned Fat32 card, containing only the firmware and ROM, is in the slot, RISC OS being on SCSI. It’s handle is 255. No such thing happens with a partitioned card where the firmware is in Loader.

P.S. Tried consulting the PRM for OS_Args. “Reads or writes an open file’s arguments, or returns the filing system type in use”. Page 2.49 ROOL PDF.

Minor correction With a partitioned Loader type card !Boot.Loader does appear as open if the Loader directory has been opened in the Filer.

Director allows you see see and close open files with a right-click on the rightmost iconbar icon, iirc.

If you want to know what files are open, use this BASIC program.
REM >FilesOpen
FOR R%=1 TO 255

I feel compelled to suggest using OS_FSControl 58 to find the open handles rather than just prodding 1 to 255 and listening for a squeak – that would obviously fall over when we unleash the full 32 bit range of possible handles.

Using 32 bit handles would also allow FileSwitch to recycle them less often (4 billion handles could just count down from &FFFFFFFF at power on) which would eliminate much of the concern about CLOSE#0 leading to task A accidentally writing into task B’s file. Even if you opened and closed 100 files a second that’s still enough handles to keep you amused for 497 days!

Even if you opened and closed 100 files a second that’s still enough handles to keep you amused for 497 days!

Memories of a bug in the sw/firmware for the Nortel Baystack 470¹ prompt me to say that it’s a bit over 497 days; by a number of hours, minutes, seconds and centi-seconds (can’t be bothered calculating the precise number)

¹ To avoid daytime clock rollover restart issues, I kept a table of expected roll-over dates and rebooted at a time of my choosing (usually between 2300 and 0000)

Interesting. https://blog.michaelfmcnamara.com/2008/06/how-much-uptime-is-too-much/

Funny to be talking about uptime after I’ve just read this story!

Interesting. https://blog.michaelfmcnamara.com/2008/06/how-much-uptime-is-too-much/

Today I learned that (presumably) Linux uses centiseconds for timers. I assumed it used something more granular, but 497 days is UINT_MAX cs.

Interesting. https://blog.michaelfmcnamara.com/2008/06/how-much-uptime-is-too-much/

Ah, Mr McNamara – source of much useful info back then.

@Sprow

I feel compelled to suggest using OS_FSControl 58

Thanks for that reminder.
The link you posted says it was added in FileSwitch 2.74 (27 Nov 2011), RO 5.20.
The OS StrongHelp manual v3.19 suggests it was added in RO5.17.
Much to my suprise, it seemed to work on RO4.02 and 4.39, but not 3.71.
I am trying to help someone who wants his program to run on as many RO versions as possible, so any clarification would be useful.

I feel compelled to suggest using OS_FSControl 58

The link you posted says it was added in FileSwitch 2.74 (27 Nov 2011), RO 5.20.
The OS StrongHelp manual v3.19 suggests it was added in RO5.17.

The wiki page is talking rubbish. FileSwitch 2.74 first appeared in RISC OS 5.17, so depending on your view the first stable release where the API would be set in stone is 5.18.

Much to my suprise, it seemed to work on RO4.02 and 4.39, but not 3.71.

Careful now, if you have CallASWI 0.07 loaded during !Boot then that implements OS_FSControl 58 on behalf of the host OS.

Perhaps this is only indirectly relevant. Lua 5.4 introduced to-be-closed local variables.

A to-be-closed variable behaves like a constant local variable, except that its value is closed whenever the variable goes out of scope, including normal block termination, exiting its block by break/goto/return, or exiting by an error. Here, to close a value means to call its __close metamethod. When calling the metamethod, the value itself is passed as the first argument and the error object that caused the exit (if any) is passed as a second argument; if there was no error, the second argument is nil. The value assigned to a to-be-closed variable must have a __close metamethod or be a false value. (nil and false are ignored as to-be-closed values.) If several to-be-closed variables go out of scope at the same event, they are closed in the reverse order that they were declared. If there is any error while running a closing method, that error is handled like an error in the regular code where the variable was defined. After an error, the other pending closing methods will still be called. If a coroutine yields and is never resumed again, some variables may never go out of scope, and therefore they will never be closed. (These variables are the ones created inside the coroutine and in scope at the point where the coroutine yielded.) Similarly, if a coroutine ends with an error, it does not unwind its stack, so it does not close any variable. In both cases, you can either use finalizers or call coroutine.close to close the variables. However, if the coroutine was created through coroutine.wrap, then its corresponding function will close the coroutine in case of errors.

File-handles are automatically equipped with __close metamethods. Some might argue that the necessity to explicitly close a file (or any other object with a __close metamethod) is good for the programmer’s soul, while others argue that automatic closure is a useful safety net.

A useful safety net for errors and crashes that shouldn’t be relied upon to tidy up after you (as in, close yer damn files!).

It’s a double edged sword really. It would be good for an environment (OS, runtime, whatever) to finish your program leaving the machine in a sane state.

But the more tidying up that is done automatically, the more people will come to rely upon that rather than bothering to do it themselves.

I really appreciate modern hire-cars that switch on the wipers when it rains, turn on the headlights when it gets dark, and dips them when there is oncoming traffic. On the other hand I loathe them when their gearboxes suffer software errors, and no reset buttons are available (so you have to disconnect the battery and reconnect to get started). The trouble with bells and whistles is that they reduce reliability because they multiply the probability of error. There have been times when wistful memories of a Morris Minor were recalled. But I agree that to-be-closed variables are likely to inculcate bad habits. It will be interesting to see what the Lua triumvirate does with them. Lua once had a macro system, like C. But it was jettisoned in the next version, reckoned as not worth the aggravation.

I really appreciate modern hire-cars that switch on the wipers when it rains, turn on the headlights when it gets dark, and dips them when there is oncoming traffic.

The guy that took me to work when mom was ill had a C4 Executive that did all that. The wipers came on, once the screen was getting hard to see out of. The lights turned themselves on and dipped themselves. It even had a button that he could get up to a speed and press and it would maintain that speed by itself until he braked.

Talking about it, he appreciated the self driving, but he would have preferred to turn the automatic lights off because his wife’s car doesn’t have all the fancy and when he uses it (when his needs repairs, which is all too frequent), he’s driving without lights and failing to dip for other cars. It’s not that he’s a bad driver, he’s just used to the car doing it for itself that he doesn’t remember it’s a manual job.

I rather imagine it would be a similar sort of OMG! for somebody used to power steering to use a non power car. You’re used to little movements, and now you have to fight the steering wheel like it’s a 737-MAX on a downward trajectory.

Like I said, double edged sword.

It even had a button that he could get up to a speed and press and it would maintain that speed by itself until he braked.

Mine has that, and it automatically slows down when the car in front does. Unfortunately it struggles with multiple lanes; the car in front indicates right and pulls into the turning bay, and my car proceeds to slow down. If left to its own devices I think it would probably come to a complete stop.

It even had a button that he could get up to a speed and press and it would maintain that speed by itself until he braked.

Mine too. It works pretty well. It’s by far the easiest way to keep to speed limits.

It is quite smart regarding lanes – it will happily overtake cars on my left, but to overtale cars on the right I have to touch the accelerator pedal to tell it so. In Germany, that logic swaps sides.

It’s great in start-stop traffic. After a few seconds stopped, the engine stops. When the vehicle in front moves it starts the engine, and waits for a touch on the accelerator before moving off. As a result I can read a book while waiting, and when I feel the engine start, I put the book down.

However the “lane-assist” isn’t so great. About 30% of the time it can’t detect the lanes and disengages. It gets confused with repainted lines in road-works too – those where the white lines are replaced by yellow ones with narrow lanes. If that’s the future of self-driving cars, I don’t want to be on the same road as them.