Service call to skip specific files on CLOSE#0

On my system:

*ListOpen
255 WR! SDFS::RISCOSPi.$.!Boot.Loader
254  R  devices#bulk;size16384:$.USB3
253 W ! devices#bulk;size16384:$.USB3
252  R  SDFS::RISCOSPi.$.!BOOT.Resources.!Fonts.Cyberbit.IntMetrics
251 WR! SDFS::RISCOSPi.$.!BOOT.Resources.!Scrap.ScrapDirs.ScrapDir.WWW.NetSurf.Log
250 WR! SDFS::RISCOSPi.$.Apps.Disc.!smbserver.Resources.ALogFile
249  R  SDFS::RISCOSPi.$.!BOOT.Resources.!Fonts.Cyberbit.Outlines
248  R  SDFS::RISCOSPi.$.Apps.Disc.!smbserver.Resources.sharepass
247  R  Resources:$.Fonts.Homerton.Bold.IntMetric0
246  R  Resources:$.Fonts.Homerton.Bold.Outlines0
*

File handle 255 is the FAT partition. I’m not sure why it’s opened read/write (with outstanding data (the ‘!’ marker)) when I’ve not accessed it, but it is always this way at boot.
The next two files are the USB Ethernet adaptor.
Also of interest here is the NetSurf log.

A long-standing issue is that *CLOSE or CLOSE#0 (OS_Find close with handle of zero) will cause all file handles to be discarded as the files are closed.

Would it not be logical to include a ServiceCall to allow things that don’t want their file handle discarded to object to this closure? For example, my MIDI module (a file for input data, a file for output data), and anything else that uses files in a similar manner.

The problem here is that while one can sit on FindV to spot opening and closing of files, this is not the case if the file handle is zero. We could trap FindV to prevent CLOSE#0 from working at all, but currently there’s no way to object to individual file closures.

The work happens in castle.Sources.FileSys.FileSwitch.s.OSFind. The CloseFile entry checks for handle being 0, and if it is, calls CloseAllFiles. After some fiddling, this goes to CloseAllFilesOnThisFS which simply branches up to CloseAllFilesEverywhere skipping over the instruction that nukes the fscb.

This is where we should stick in the ServiceCall to allow modules to veto file closures. This is because the FlushAndCloseStream code works on the assumption that errors will be noted and ignored, the stream will be deallocated regardless. So it would make more sense to present the handle and allow a veto prior to calling that.

There should be no caveats regarding file handles lingering during shutdown because:

• this is intended for Device file handles (although could be used for FS file handles)
• DeskTop shutdown will finish with a Service_ShutdownComplete (the traditional “It is now safe to turn off your computer” message) at which point anything using FS file handles in this manner could probably assume that it’s time to close the handles. Device handles could remain active, there’s no risk of FS corruption from them.
• there’s also Service_DeviceDead that DeviceFS will give if there’s specific reason for the device’s handles to be closed. [example from MIDI, unplugging the device would do this ;-)]

Thoughts?

Is there any justification for allowing *CLOSE or CLOSE#0 to work?
A simple module could sit on FindV and trap close all calls, either displaying an error window to confirm or just returning an error to the caller.
Desktop Shutdown may need special handling. Are there any other legitimate uses?

Are there any other legitimate uses?

<shrug> I don’t think I’ve really had a legitimate use since FileStore issues on a BBC Micro (left lingering handles). Used it a few times out of laziness on old ARM but since the A5000 and big programs that crunch data (Usenet, Fidonet, etc) it’s just not been a great idea…

Is there any justification for allowing *CLOSE or CLOSE#0 to work?

CLOSE#0 is listed under “Window managed programs – Instructions to avoid” in the BASIC Reference Manual :)

It’s also noted that “you should not use the CLOSE#0 form within programs”, although it goes on to say that it can be used for debugging.

I am currently testing a small module StopClose0 which traps *CLOSE and CLOSE#0, and asks the user to Allow or Fail it. I am just debating if it needs to disable itself when Service_Shutdown is received. Seems to work without problems so far here … anyone interested PM me.

Have the feeling that this problem came up in the ‘Risc User’ Mag – and perhaps a module was produced – but can’t find it.

Does your module help if a ‘C’ or ‘ARM’ program does a global CLOSE?

The point here is one faulty prog can say – close a SparkFS ZIP file :-(

Just one example !TaskUsage !RunImage -:

Doesn’t seem to do check O% for zero – before calling CLOSE #O%

Seems like several progs – that do this :-(

Does your module help if a ‘C’ or ‘ARM’ program does a global CLOSE?

Yes.

Just one example !TaskUsage !RunImage -: Doesn’t seem to do check O% for zero – before calling CLOSE #O%

I think you will find that it does – after the OPEN and before the BPUT & CLOSE

I am currently testing a small module StopClose0

I have one on my machine, sits on FindV and just swallows attempts to CLOSE#0. I didn’t mention it before as I’m not sure which machine it is on.

CLOSE#0 does seem to be a bit of a foolish thing for BASIC to support. I expect that the number of legitimate users is small enough that BASIC could be changed to ignore CLOSE#0 without any significant repercussions (if BASIC programs really want to close all files, they can just change to SYS “OS_Find”).

Some way of protecting DeviceFS from *Close is certainly desirable, although I’m not sure what the best method would be. It may well depend on the intent behind the *Close operation (am I a portable device that’s about to run out of battery and wants to flush all pending writes to disc? Is the disc/device about to be ejected? Or has the device already been ejected and I’m having to deal with it? Is the OS shutting down? etc.)

Previous thread: https://www.riscosopen.org/forum/forums/4/topics/1271

CLOSE#0 does seem to be a bit of a foolish thing for BASIC to support. I expect that the number of legitimate users is small enough that BASIC could be changed to ignore CLOSE#0 without any significant repercussions

I agree. I would support such a proposal.

I can’t imagine any legitimate use for CLOSE#0.

Here’s an example of code that I use to avoid an accidental CLOSE#0:

DEF PROCclose_file(RETURN file%)
LOCAL ERROR
ON ERROR LOCAL file% = 0
IF file% <> 0 THEN
 CLOSE#file%
 file% = 0
ENDIF
ENDPROC

which only works if a call to PROCclose_file is the only way you close a file.

To try and identify any cases where Close All (OS_Find,0,0) is used legitimately, and possibly some illegitimate uses, my module is now available. It prompts the user to allow the operation – if not it errors the action. I will add it to my website soon, but PM me if you would like to try it. It is in use here from boot.

This should help identify if Close All can be stopped at a lower level than BASIC, which is only part of the problem.

Some way of protecting DeviceFS from *Close is certainly desirable,

Hence my service call suggestion. Things talking via DeviceFS are probably modules (or back end via modules as is the case of things like SerialUSB) so could remember file handles and veto a close.

I’d agree that BASIC should be prevented from doing CLOSE#0. That, with the ServiceCall veto, ought to cover most cases without nuking the “close all files” concept completely.

Or has the device already been ejected and I’m having to deal with it?

You don’t need to worry about that. You should see DeviceDead long before anything bothers you about closing files.

It’s worth noting that there are two very different types of file handle in question. One is a traditional “handle” that to relates to an actual file. These need to be sorted out when the machine shuts down.
The other type of handle is that to a device. Serial port, MIDI, Ethernet (or so it seems), plus the old style devices (vdu:, printer:…). In these cases, usually a tidy shutdown is desirable but not essential. It’s not really that big a deal if there’s data outstanding in a virtual device if the machine is about to go down…

CLOSE#0 does seem to be a bit of a foolish thing for BASIC to support.

Well … ;-)

Basalt ignores CLOSE#0. CLOSE#file% also sets file% to 0 and removes the handle from the list of files to be closed on QUIT. Making CLOSE ‘safe’ was one of the earliest things I implemented.

if BASIC programs really want to close all files, they can just change to SYS “OS_Find”

Or *Close or even *Shut.

Here’s an example of code that I use to avoid an accidental CLOSE#0

I think if you use the SWI directly you can avoid the error:

DEFPROCclose(RETURN file%)
 IF file% THEN SYS"OS_Find",,file% TO file%:REM also sets file% to 0
ENDPROC

Or *Close or even *Shut.

What’s the difference? Wasn’t one supposed to do it per FS and one globally… or was that Arthur/RO2?
[yeah, it’s been a long time since I used either command]

What’s the difference? Wasn’t one supposed to do it per FS and one globally… or was that Arthur/RO2?
[yeah, it’s been a long time since I used either command]

*h. close
==> Help on keyword Close
*Close closes all files on the current filing system.
Syntax: *Close
*h. shut
==> Help on keyword Shut
*Shut closes all open files on all filing systems.
Syntax: *Shut

I suggest making CLOSE#0 close all files opened with OPENIN, OPENOUT and OPENUP in the same instance of BASIC, thereby restoring the pre-RISC OS behaviour, which only effected the current program because there was only one program, which was actually useful.

I suggest making CLOSE#0 close all files opened with OPENIN, OPENOUT and OPENUP in the same instance of BASIC,

Is this not the programmer’s responsibility? The use of CLOSE#0 was partly laziness (stuck? just close everything!) and partly because error handling in older BASIC wasn’t as advanced.

thereby restoring the pre-RISC OS behaviour,

It’s not right to compare a non multitasking system with scant resources that hardly ever kept files open with a multitasking system where not only are resources frequently held open (FontManager) but devices can be associated with file handles and these held open too.

If we are going to suggest restoring behaviour from the early eighties, would you agree to petition Jeffrey to modify GraphicsV to permit only MODES 0 to 7? Imagine what MODE 2 would look like on a 28" display! ;-)

A long-standing issue is that *CLOSE or CLOSE#0 (OS_Find close with handle of zero) will cause all file handles to be discarded as the files are closed.

It is only all file handles on the current filing system. If *CLOSE is trying to close all files on all filing systems then that is a serious bug in RISC OS.

It will (should) therefore discriminate (in your example) between SDFS, devices and resources.

The command to close all files on all filing systems is *SHUT.

I use *CLOSE during debugging if I have a multi-tasking BASIC application running that logs various things and it falls over and has to be killed. BASIC (or the Wimp) is not clever enough to close all files that an application has opened when it is killed. I avoid shut because of the side effects on streams and things, network for example.

I suggest making CLOSE#0 close all files opened with OPENIN, OPENOUT and OPENUP in the same instance of BASIC

That might be useful, once BASIC keeps a list of open files a la Basalt. I would look at CLOSE LIST as a more suitable syntax.

That might be useful, once BASIC keeps a list of open files a la Basalt. I would look at CLOSE LIST as a more suitable syntax.

Yes. CLOSE#0 should throw an error. (If you really want to do CLOSE#0 use *CLOSE.)

If CLOSE#0 does close all files on the fcurrent filing system, then would making the current filing system RAMFS solve most of the problems?
I’ve just tried this on the armX6 – doing *ram, then *basic, then CLOSE#0 doesn’t close the open file on SDFS (plingusbkick.!run in this case). Nothing seems to have broken when RAMFS is the current filing system.

The most often error is the following;

fh%=OPENOUT"SDFS::0.samefilename"
...
IF fh% THEN CLOSE#fh%:fh%=0
...
CLOSE#fh%

I don’t see why not. CLOSE# is using a file handle, not the name. You can close a file on SDFS while the default filesystem is set to RAMFS. It just means that if the handle happens top be 0, then the files closed are those open on RAMFS, and these are likely to be less important.

(How on earth do you quote on this system? The textfile reference is useless.)

Yes, I see what you mean but I sometimes use RAMFS to test an application. I also rely on the CSD, especially during testing (and so does the rom compilation process).

(How on earth do you quote on this system? The textfile reference is useless.)

You type “bq.” and a space at the start of the paragraph. There is a hint in the formatting help just under the Reply box.

If you want to quote several paragraphs you can just put the HTML blockquote tag round them.