Provide an option to re-open the .ssd if it hasn't been accessed for a few seconds

[ZornsLemma]

I appreciate this might be a bit niche...

I'm working on a project which I build on the Linux host which is also running b-em. It builds a .ssd file using beebasm as the last step of the process, and I have that .ssd file mounted as disc 0 in b-em. (Which I am using in Master Turbo mode, on the offchance it matters.)

If the .ssd file is updated in-place by beebasm, b-em sees the changes automatically and everything is fine.

If I do a make clean+make, the .ssd file is deleted by the "make clean" and then gets recreated later on by the "make". b-em continues to use the old version of the .ssd, which can be confusing (and now I'm aware of it, means I get paranoid and keep re-loading the .ssd from the b-em menu when I probably don't need to). I guess this behaviour arises from the normal Linux/Unix file handling; the 'deleted' .ssd remains available until the last handle to it is closed, and b-em has a handle to it so continues to be able to access it, but it would be super convenient for me if b-em could optionally close the .ssd and re-open it every few seconds, or do this if it hasn't been accessed for a few seconds, or something like that.

There may be better ways to handle this, but if no one objects or has a better idea or implements it first I might look at producing a patch to do something like this (controlled by an option, as it might harm performance). I thought I should raise this issue to see what people think before doing anything myself.

[richardcrossley]

If the file is open in B-em and beebasm "deletes" the file and recreates it, it's really a different file, just happens to have the same name.

Correct me where I'm wrong, but I see the events as follows:

• The file's inode is found using the file name.
• The file's inode is used open the file in Linux Kernel.
• Beebasm deletes the directory entry and writes a new file with the same name.
• The original file's inode remains open in B-em which prevents the Kernel from physically deleting the file.
• B-em doesn't notice the change to the file because the inode has not been updated.

To implement the required behaviour wouldn't B-em need to:

• Close the file
• Rescan the directory
• Reopen the file

[ZornsLemma]

Hi Richard,

That sounds right to me, except I don't think the "rescan the directory" step is something b-em has to worry about; I'd expect that to be done by the kernel as part of handling the open("filename.ssd") call which I'd like b-em to (optionally) make.

You're right that it's really a different file, just with the same name, but I'd like b-em to optionally assume that it's the filename which I (as the user) care about, not the file. I could imagine the current behaviour is desirable in some cases, e.g. someone downloads a .ssd from stardot to a temporary location using their web browser, opens the .ssd in b-em then the temporary location gets cleaned up and the .ssd removed while b-em is still using it, which is why I'd propose this as an option not the default/only behaviour.

Cheers.

Steve

[SteveFosdick]

It's interesting how coming from a different background one can have a different approach. From DOS or CP/M days closing a file if you were not going to be accessing it for a few seconds seemed quite normal and there was some extra complexity to come from doing that, for example:

The CP/M submit program (equivalent of *EXEC) writes the commands into a working file in reverse order so each time the command processor (CCP) opens the working file and reads a command, it can make the file one record shorter and close it again. Once the file is empty is it deleted and control returns to the keyboard.

I don't think DOS does anything quite like that but it does close batch files and re-open them between each command so if one of those commands was to replace the batch file with something different batch file execution would carry on from the new file at an offset relevant to the old file, i.e. not necessarily at the start of the line.

Back to the subject in hand, if you did want to implement this feature the obvious way to hook it in is with floppy disc spin-up/spin-down, i.e. when the virtual floppy is spun-up the file is opened and when it spins down the file is closed. That way, it matches what DFS is doing about re-reading the catalogue to cope with disc changes.

The other option is to use VDFS rather than an SSD to transfer code from BeebASM on the host to the guest to run. That shared hosts file directly and open/close of the host file corresponds 1:1 to open/close of the file from inside the BBC guest. I did write some documentation on VDFS here: https://stardot.github.io/b-em/vdfs.html

[SteveFosdick]

Is this still a problem? I checked beebasm and it seems to be opening its output file for write/truncate in the usual way, whether a simple binary file or a disc image, so this should overwrite the file even if b-em has it open. Where it might go wrong is if beebasm saves the file in one place and then a script/makefile moves it to another - cp to another place would also work fine.

[ZornsLemma]

The behaviour I originally noted is still present. I can reproduce this by having foo.bas:

PRINT "1"

and z.beebasm:

putbasic "foo.bas", "foo"

If I build:

beebasm -i z.beebasm -do z.ssd

and Disc->Load z.ssd into b-em, it's fine - CHAIN "FOO" shows 1.

If I change foo.bas to print 2 and re-build, CHAIN "FOO" shows 2, which is great.

If I change foo.bas to print 3, delete z.ssd and re-build, CHAIN "FOO" still shows 2, and I have to do the Disc->Load to get b-em to see the newly built version which prints 3.

Obviously this is a contrived example, but the situation I originally encountered it was doing make clean (which deletes the .ssd) then make; this feels like it should be a "really clean" build, but it's actually worse in some ways because b-em will end up with an old copy of the disc.

I haven't put the effort in to create a patch for b-em to handle this in any way yet, so I'm not going to complain if you close this, but I still think it would be nice if this worked automatically.