VDFS - *ADFS

[mark-usher]

Not sure if this is a user error or a VDFS error. If I build an exec file e.g. "TEST" containing ADFS and EXEC the file E.TEST There is an error "Channel on channel xx" Whereas typing ADFS at the command prompt works correctly.

[SteveFosdick]

What I think is happening here is that nothing is closing the EXEC file. The OS would ordinarily close it after it has got an EOF indication from it but that may not be happening when the *ADFS command is being read.

VDFS is not closing it when ADFS declares it is taking over the filing system vectors because, at least on the Master, filing systems are supposed to be able to keep files open while other filing systems are selected and the Master file switch takes care of tracking which channel numbers belong to which filing systems.

So then, on a Model B, the OS tried to read from the VDFS EXEC file while ADFS is the current filing system and ADFS doesn't know that file channel.

Do you have any thoughts on what should be the correct behaviour?

[mark-usher]

Thanks Steve for the analysis. Very interesting. It's difficult to say what "should be the correct behaviour" - the expected behaviour was the EXEC file would execute the script in its entirety as if entering at the keyboard. e.g. ADFS TITLE MYDISK OPT 4,3 CDIR LIBRARY VDFS COPY !BOOT ADFS::0.$.!BOOT *COPY PROGRAM ADFS::0.$.PROGRAM (it doesn't like the ADFS::0.$.xxxx syntax either from the command prompt, but I'm not sure if that is me or VDFS).

Perhaps this is me being too hopeful, but the error message with the channel was very unexpected. COPYFILES (v3.60) does work currently between VDFS and ADFS but I was trying to do more than simply just copy some files.

[SteveFosdick]

Mark, where does that ADFS:filename syntax in *COPY come from? Is it NFS/Econet as I have not seen it before.

I will have to test it, but I think what you are hoping for may work on a Master because the *ADFS would make ADFS the "permanant" filing system but the file switch would temporarily switch back to VDFS to continue reading the EXEC file, though the Master syntax for a temorarly filing system is -fs- rather than fs:

On a BBC B, you could possibly work around switching away from the filing system that is hosting the EXEC file by programming some commands into a soft key with KEY, inserting that into the keyboard buffer with the relevant FX, then have the last one of these commands *EXEC a second file to continue,

What makes this complicated is that the EXEC file is not read into memory when first opened or stuffed into the keyboard buffer but read one character at a time with OSBGET. So if BASIC if the current language, BASIC asks for the next line of input via OSWORD 0, that internally calls OSRDCH to get characters to assemble the line of input and OSRDCH notices there is an EXEC file open and fetches a character via OSBGET rather than trying to remove a character from the keyboard buffer.

[SteveFosdick]

I did some testing by creating an EXEC file on an (emulated) ADFS hard disc with the contents:

*status
*tape
*help

Running this on a Master works, i.e. the output of status and help are both visible. Running on a BBC B causes the exec file to be abandoned when TAPE takes effect, i.e. the help is skipped. I'll do some digging and see what is doing that.

[SteveFosdick]

Running on a BBC B with ADFS as the old filing system, hosting the EXEC file, and TAPE as the new filing system, the sequence of events is:

1. TAPE filing system issues FSC call A=6, new FS taking over.
2. ADFS implementation of FSC A=6 calls OSBYTE &77 to close SPOOL and EXEC files.
3. OS issues ROM service call &10 - nothing claims it.
4. OS issues OSFIND to close the EXEC file.
5. Returning from OSBYTE, ADFS packs things into private workspace and returns.

[SteveFosdick]

By comparison, MOS 3.20 with ADFS 1.50, *TAPE still issues FSC A=6 but the ADFS handler for that does NOT issue OSBYTE &77 so SPOOL/EXEC files are not closed.

The ADFS handler for FSC A=6 also does not issue OSBYTE &77 - all it does is note it is not the current filing system any longer. Perhaps it needs conditional code to do the OSBYTE &77 if the machine is something prior to the Master.

[SteveFosdick]

I have pushed a fix to the same branch as issue #187, https://github.com/stardot/b-em/commit/8761065a444c7d56362121ff99aaa5eddeb38d84

[mark-usher]

Checking around, the ADFS::$.0.filename syntax appears to come from RISCOS. I thought I had seen it in use on a BBC Master, so that may have been related to network operations. The implementation of that in VDFS e.g. for a COPY would then be a feature request rather than a bug/issue. I tried the EXEC file on a Master, and as you thought it does operate as expected (except for the copy commands).

I suppose the question now becomes, 1) should VDFS behave exactly the same way as ADFS except it uses the host file system instead of emulated media, or 2) should VDFS have the behavior of ADFS and extra functionality to aid modern usage scenarios?

I appreciate very much the time taken for the analysis and fix you have put in place.

[SteveFosdick]

Mark,

On the question of what VDFS is trying to be, the idea was to provide access to files on the host in an easier way than having to copy them into/out of SSD files. As Linux and Windows both have a hierarchical filing system it made most sense to make VDFS ADFS-like, though VDFS does also have a DFS-like mode*.

When working like ADFS, I want it to be close enough that software designed for ADFS will work but if it can be extended beyond ADFS in ways that don't break ADFS compatibility then I am quite happy with that. Already, returning "others" file permissions and the host file date stamp are more like NFS than ADFS and it also treats '&' (user's home directory) the same as root.

On *COPY being able to copy files between filing systems, how easy that is depends very much on whether wildcards are needed. AFAIK, most filing systems provide an OSGBPB call to read the filenames in a given directory but not a call to find the list of filenames that match a wildcard so COPY may have to do that too.

JGH's TreeCopy program, written in BASIC, does quite of lot of the rest of what would be required, i.e. for small files it loads as many as it can into memory with OSFILE, switches filing system, then writes them out again whereas for large files it copies chunks of the file with OSGBPB.

• DFS-mode is selected with

  *VDFS D

  It leaves the current directory as-is, so it is possible to navigate to a directory with *DIR in ADFS mode, then swaps to the DFS single letter concept of directories where the letter is stored in the .inf file, not real sub-directories on the host. This is specifically for running software that has been written around this behaviour of DFS. Running:

  *VDFS A

  gets back to ADFS mode where *DIR moves around the hierarchy again.

[SteveFosdick]

I have created a release with Windows binaries: https://github.com/stardot/b-em/releases/tag/vdfs%23186

[mark-usher]

Thank you Steve for such an indepth and thorough answer. The BBC certainly exits more gracefully now instead of the channel error when the filesystem changes through an EXEC file. It looks like the Master is the way to go to set up the disc with TreeCopy to move the files instead of the BBC with the 256K turbo and an EXEC file or an Archie with an EXEC file might also handle it as a script as I'd originally thought. Thank you again.