Filesystem Special Fields Page Zero access

I’ve come across a possible bug in FileSwitch, but would like to test it with another filesystem that supports Special Fields – does anyone know of any 32-bit FS that do?

I’m seeing a Page Zero access when FileSwitch touches PassedFilename when directories or wildcards are used. I don’t see it with individual files though. For example, if I Count files in a test directory FileSwitch Aborts:

SYS "OS_FSControl",28,"CFS#RAM::0.$.TestDir" TO ,,S%,C%

But if I count one file in the folder, it returns the correct values:

SYS "OS_FSControl",28,"CFS#RAM::0.$.TestDir.AFile" TO ,,S%,C%

PassedFilename appears to be 0 when a directory or wildcarded filename is used.

As you can see in the examples above, I’m using a 32-bit version of CFS that I converted. Its possible its related to that, but having added debug output I can’t see FileSwitch calling any of the CFS entries prior to the Abort in FileSwitch.

Note the Page Zero Compatibility page needs to be disabled to see the Abort, which can be done via:

SYS "OS_Memory",20,0

Isn’t e.g. the “notypes” parameter of LanMan98 such a “special field”? And the whole USB stuff via DeviceFS? The latter being a bit more difficult to reproduce your test case with…

From further testing this morning, I’ve noticed that if performing the test above directly after power-on doesn’t Abort. It only starts Aborting sometime later.

I’ll do some further digging and provide a Repro if applicable. I’m now wondering if a 3rd party is affecting FileSwitch in some way or corrupting PassedFilename.

EDIT: It’s not occurring after boot as the Page Zero Compatibility page is enabled by default. After turning it off the Aborts occur, I’ve noted that in the OP.

The root cause is the “duff filesystem” code in LowLevel

Further up there’s a DuffFSTable and in that list it has 38 (CFS) set as “duff”. If I change the CFS filesystem number to something that isn’t in the “duff” list the Abort doesn’t occur.

It should be noted that the filesystems in DuffFSTable doesn’t match the Wiki Filing System Numbers list. Using CFS as an example, its correctly listed in the Wiki as “38 – CFS” but listed as “38 – PC” in LowLevel.

So the issue is a bug in FileSwitch, which is only triggered when FileSwitch checks for the absence of a “$” on a “duff” filesystem.

Perhaps a review of that table is also needed as it dates back to RO3?

I’m not sure how to proceed. Can 38 (CFS) be removed from the “duff” list by an OS developer? If not, I’ll request a new filesystem number for CFS.

Does anyone know if DuffFSTable is actually still required?

It looks like a “hack” put into RO3 to work around differences with RO2. I doubt any filesystem in the list has a 32-bit Module and if they do they should have been updated to the revised documentation, so I would say the table and its associated code in SortSpecialForFSEntry and SortSpecialForFSExit are now redundant?

I’ve posted a Repro here

According to the software compatibility page, ArcFS 2.60 is 32-bit OK. For the rest of the table, I have not even ever heard of most of these filing systems.

is 32-bit OK

ARMv7 (doesn’t use rotated loads)?
ARMv8 (doesn’t use SWP)?

I’m not expecting an answer, just pointing out that the phrase “32 bit okay” is only half a guarantee that something will actually work. ;)
After all, take a look at the various incarnations of Samba, WebJames, even Zap. Some builds work on some systems but not on others.

Though, this is arguably more an issue with the general situation and continual revisions to the ARM than anything else.

According to the software compatibility page, ArcFS 2.60 is 32-bit OK

ArcFS has been 32-bit for a while as I’m using 0.75 on a Pi3 without issues. I’ll see if it also causes FileSwitch to Page Zero access with the Repro.

Reportedly fixed Version 2.89. FileSwitch