Closing all open files

Is there an equivalent of OS_FSControl 22 to close all files currently open by a task?

Failing that, is there a way to retrieve all open file handles and their associated task?

AFAIK there is no task information associated with an open file, so I doubt RO can do close all for a task, or even list them with task.

OS_FSControl,22 is one of the things trapped by my StopClose0 module, as it is so dangerous. And it identified a new errant program only yesterday!

There is no association between file handles and tasks, what task would you even associated to files opened by modules or non-wimp applications?

The SharedCLibrary maintains a list of handles opened via fopen() and closes automatically any file left open on exit of the program even when the program crashes. Well that is for the most simple crashes, when it detects memory corruptions for example, the atexit() routine is not executed leaving everything open. IIRC the same occurs when you Alt-Break the program.

It seems to me that it would be possible for RISC OS, at a system level, to make a note of which task was paged in when a particular file was opened. That would allow a file handle to be associated with a task name. I don’t think it does this at present.

That’ll be fun with stuff that uses files on callbacks (modules, I have several that do this) and other behind the scenes stuff. ;)

The SharedCLibrary maintains a list of handles opened via fopen() and closes automatically any file left open on exit

Basalt does this for files opened with OPENOUT etc as statements and closes them on QUIT. ;-)

Basalt does this

Still think this deserves a place of pride within the OS proper… ;)

Thanks for the responses. As I suspected, I’ll need to implement task/file-handle associations.

files on CallBacks / Modules

Modules are tracked by CAO but I’m not sure if CAO is set before the OS enters Module CallBacks or Vectors. Somewhere in the docs it does state Module Finalise should handle terminating CallBacks etc, but there’s obviously a grey line where a task asks a Module to perform a file action and the task is then terminated.

There doesn’t appear to be an UpCall for task termination, so I’m unsure how Modules would be notified to clean up when a task is terminated.

I was thinking more in the context:

Foreground application opens files.
A module, upon setting itself a callback, opens a file in the background.
The application crashes.
Something steps in to tidy up the lingering files.
Does it know to leave the module’s file alone?

RISC OS desperately needs proper resource management, and particularly before it can move to being multi-processor aware. Resources need to be tracked by both active task and location of the call stack, to be able to tie the resource to a application or a module. But then there can be code in the module area which is outside any module, so god knows what you do about that.

I understand the need for all this discussion, although perhaps not the discussion itself.

My only comment is, please do not remove the option for somebody sat at the keyboard to manually close all open files no matter how they were opened.

Yes, it is dangerous, but not so much so as the alternative. We humans can make that decision.

Yes, it is dangerous, but not so much so as the alternative.

What alternative? Perhaps you aren’t aware of the problem, so let me elaborate.

RISC OS hands out file handles from #255 downwards. Things open files, get assigned a handle, read and/or write to them.

Yes, I can fully understand being able to close a specific handle if something crashes and leaves files open.

But closing all files is bad, bad, bad.

The reason is that if a file is forcibly closed, the module or application may not be aware of this. It won’t be trapping such activities to check because the file handle is the responsibility of the file owner, nothing else.

Now this doesn’t sound too bad until you remember that file handles are assigned from 255 downwards. So something may open a file and get given a handle that something else already thinks it owns. The other program is perfectly at liberty to dump data to this handle, after all, it opened the handle first.

You may not have much experience with this problem, but back in the mid 90s I used to run a BBS using ARCbbs and archives managed with SparkFS. Both of which hold files open. Then along comes some crap software, like FormEd (Acorn’s miserable excuse of a Template editor) that silently does a CLOSE#0 ¹ and, well, then the 💩 hits the fan. File corruption was frequent, as things would end up with file handles that other things had been using. What cured this was to hijack the OS_Find vector and block such horridness.

These days? Even devices can be assigned file handles. Not to mention the FAT partition, if you’re booting from a dual format SD card.

It’s why I’m a firm believer that multitasking applications should never hold files open between polls.

Frankly, CLOSE#0 is an abomination that should be taken outside and shot.

I have written two programs. The first is called ListOpen that will list all open handles (IIRC the source for this is in the wiki somewhere), and a little BASIC program called CloseOpen that accepts a handle by number and closes it.
That way, specific files can be closed, but you have to think about what you’re closing rather than blithely closing everything and hoping that you don’t discover some nasty corruption a few months down the line…

So I don’t think you appreciate how dangerous closing all files can be, and that any alternative is better.

¹ Finally fixed two years ago…

RISC OS desperately needs proper resource management

Something that would be nice is being able to tag all of the billions of random blocks claimed in the RMA with what claimed them. Might help chase down those things that make RMA claims and then don’t (for whatever reason) unclaim them.

to tag all of the billions of random blocks claimed in the RMA with what claimed them

.. and when, perhaps? I presume that RISC OS, like BBC BASIC, was born too early to have anything like a specification . Back-porting a rigorous algorithmic description that most nearly fits RISC OS I should imagine to be a Sisyphean task.

I don’t know whether RISC OS had a specification or not, but plenty of things – even some software – did at the time, and indeed much earlier.

Arthur specification: BBC MOS, on ARM.

RISC OS 2 specification: Add useful things to Arthur. Make the desktop work. Get rid of those horrible colours.

RISC OS 3 specification: A load of stuff that was on the wishlist that we didn’t have time to do when trying to bury the ghost of Arthur.

RISC OS 3.5 specification: The least possible to make it work on entirely different hardware.

8~) Sounds about right!

I remember getting specs not so wildly different from that from systems analysts, for COBOL programs designed to handle million quid contricks contracts. And I was working on temporary contracts writing them, for mew’ssake…for peanuts…

RISC OS 3.5 specification: The least possible to make it work on entirely different hardware.

RISC OS 3.7 specification: must work on StrongARM, available developers to do the work: 1 at most

That was my take away from the June 2021 ROUGUL talk by Mike Stephens. It really explains a lot about what the situation was back then at Acorn. I remember quite a few discussions back then in csa.* where all were very depressed about the lack of new features in RISC OS 3.7 – if we knew it was basically done by one guy…

I have seen all of the reasons for not closing all files.

But, when I am developing an application which makes extensive use of RAM files and there is nothing else I am interested in, I want a quick way to unlock files when my current test fails.

To be clear, I am not interested in BASIC CLOSE#0, but I do want *close to work on the RAM Disc.

Try *-ramfs- close
or
*ram
*close

Oops. That should be *-ram-close

The close command closes all files on the current filesystem. the dash command makes the specified filesystem the current one for the duration of the star command (only).

yes. That works, Thank You

Can I assume that will continue to work post 5.28?

My only comment is, please do not remove the option for somebody sat at the keyboard to manually close all open files no matter how they were opened.

With proper resource management the files automatically close when whatever opens the exits. The way you manually close them is by killing what opened them. You never have the option of closing files which are still in use.

So long as *close still works until the OS has “proper resource management” I will be happy.

Until then my software now has OSCLI("*-ram-close") at the end. Now I can easily see what is in the files.

I want a quick way to unlock files when my current test fails.

*-ram-close

That may be fair enough while in an early stage of development, but if the test fails and leaves files open, then perhaps the error handling could/should be improved to close them? Even when development is complete, programs have a nasty habit of failing occasionally, and the error handler should tidy up nicely. And yes, I appreciate that is sometimes not easy.

and the error handler should tidy up nicely.

If the error has been detected, that is.

But thank you all for your comments. They are appreciated.

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