OWNER doesn't seem to track the CSD correctly

[philpem]

Client station is a RISC PC with Acorn NIC-port Econet card (modified with LS123 timer chip to fix a known hardware bug). Econet bridge software version 2.1-pre, https://github.com/cr12925/PiEconetBridge/commit/f64d011c31468526d24c4fe2e9bdaa10e0b41f0c

I've created a new user with +S (superuser) permissions and logged in as them. This means they have their own home directory, unlike SYST (whose home directory is the root).

When I logged in as them, I tried to check the ownership of the root directory - and it seemed like *OWNER wasn't tracking the CSD correctly:

*Net
*I AM 254 philpem : 
Password: (redacted)
*.
Dir. Net::Leodis.& Option 00 (Off) Owner
CDS  Net::Leodis.&
Lib. Net::Leodis.$.ArthurLib

*Dir $
*info Syst
Syst    DWR/   Directory 0000000 00000000   4 Kbytes
*owner Syst
Not found
*.
Dir. Net::Leodis.$ Option 00 (Off) Public
CSD  Net::Leodis.$

If I provide an absolute path, it works fine:

*Owner $.Syst
Owner: SYST     0000

I assume the 0000 is the user number, as my new user has id 5. I've not been able to *Type %PASSWORDS (per the Readme) to list the known users and confirm this - it gives the error "Not Found".

[cr12925]

Ok, this works fine on 8 bit clients. On a 32 bit client, what RISC OS 3 on my A3000 does when you do the "*dir $" is not actually open the replacement directory. What it does is get the object information for it but nothing else - it does not, for example, open $ as a handle and then refer to that handle.

So the FS is tracking CWD as the new syst user's home directory - which does not contain the dir name on the end of Owner when that is issued. Thus 'Not found' is returned, because OWNER will look in the original CWD, which is the new user's home directory, not $. Hence giving a full path works.

If what you do is "." after "dir $", RISC OS will - even from the command line - send the FS three handles: the URD (which is unchanged), the CWD (which by then is in fact the same as URD for some reason - and thus not $) and LIB (which is unchanged) - but will send a full path including disc name for the $ you want to see. So that works. But it doesn't do that with *OWNER, so that fails.

Not sure why RISC OS does that. 8 bit clients open $, get a new handle, and send *OWNER with the new handle as the CWD...

Any ideas?

[cr12925]

After further investigation, I think this is RISC OS getting things wrong on an F12 Supervisor prompt. If you do the same thing in a Task Window, it works. What is happening is that a DIR in a Supervisor prompt does not send the request to change directory to the server, so the subsequent OWNER (with a relative path) is interpreted (correctly) by the server as a request within the directory you think you just left. If you do this in task window, it works - because RISC OS is sending the correct request to the server (namely to change directory), it would seem.

My present diagnosis, absent some countervailing suggestion, is that this is a bug in RISC OS. *OWNER is a builtin rather than a binary, so the server has to operate on the handles which are provided to it by RISC OS. And the CWD handle given by RISC OS in the example given is for $.[urd] where [urd] is the home directory of the new non-SYST system user you created.

[philpem]

In that case, it sounds like we've hit another RISC OS oddity - thanks for the workaround. It might be helpful to make a note of these 'known issues' in a README in the /docs directory, or a post on somewhere like Stardot. It seems like NetFS has no shortage of them - and perhaps some of them could be fixed eventually...

[cr12925]

Happy to document. It's weird though - I suspect RISC OS "knows" some commands have an object name in them and "adjusts" them to its view of CWD (eg *ACCESS). The ones it doesn't, it leaves unadjusted but doesn't tell the FS it's changed CWD! Hence it goes wonky. Will leave open to remind me to note it.

[cr12925]

RISC OS doesn't update its CWD in supervisor mode - cannot fix. Probably need to write a binary that uses one of the new PiFS Operations that can get this sort of information out of the FS.