IntroductionThe password file resides on the root of a valid server disc as
It is my understanding that all valid discs must have a password file. However, there is no reason why the password file (on, for example, a floppy), cannot be empty.
When you *FSFormat a floppy disc, it writes a blank password file containing one entry - Syst, with no password.
The password file format specified below is compatible with Level 3, FileStore and awServer.
Level 4 user files are very different. The Level 4 server comes supplied with a user editor, but this editor cannot cope with the older type of password file. However, the product I recently mentioned can cater for both types of user file! ☺
File formatEach user in the password file format has 31 bytes to describe them. The file must be padded out to a whole sector (file size must be a multiple of 256 bytes) so the only clear way to count the number of users is to step through the file and see how many there are.
The user's filesThe user name is also the User Root Directory. Therefore if the user is called Amelie, she will have read/write access to the files within
If the URD is not present, the user will have read-only access to the root directory.
By default, files written to a user's URD are assigned RW/ access, which means Amelie would have full rights to her own files. Other users will be able to see what files she has (the contents of directories are not hidden) but they will not be able to access any of her files.
The final option is full access - such as WR/wr. This means the file may be read and written by anybody. The danger here is that it may also be erased by anybody. If you were to set the Locked attribute (i.e. WRL/wr), the file could not be deleted except by yourself. However a malicious user could blank the file which is as good as deleting it...
Quirk warning!The Level 2/3 user's guide states the following, and as the FileStore is essentially a ROM version of Level 3, this applies to that server as well:
You have owner access to your own main directory and sub-directories, but public access to any directory that you specify beginning with a $ or that you reach (using *DIR) via the root directory.
The situation is even worse on a RISC OS machine if you are using the command line (it's okay within the Desktop).
*I Am Amelie *. Dir. Net::FSdisc.& Option 00 (Off) Owner CSD Net::FSdisc.& Lib. Net::FSdisc.$ MyDoc WR/ *Dir $ *Dir Amelie *. Dir. Net::FSdisc.$.amelie Option 00 (Off) Public CSD Net::FSdisc.$.amelie Lib. Net::FSdisc.$ MyDoc WR/So we log in as Amelie (no password) and we then go to the root directory and back again as stated in the example. But, look, you see the top line of the directory it said "Owner" in the beginning? Now it says "Public".
*Dir $.Amelie - won't work!
I can imagine things like this could freak out a generation of non-geeky schoolchildren. Without the obvious solution - logging out and back in again - how the heck is Amelie expected to get proper access to her files?
Transcript time again:
*. Dir. Net::FSdisc.$.amelie Option 00 (Off) Public CSD Net::FSdisc.$.amelie Lib. Net::FSdisc.$ MyDoc WR/ *Dir & *. Dir. Net::FSdisc.& Option 00 (Off) Owner CSD Net::FSdisc.& Lib. Net::FSdisc.$ MyDoc WR/There you have it! The venerable ampersand, hijacked by France Telecom (latterly "Orange") and used and abused by all manner of Internet-related stuff that thinks the 'at' is passé - forget all of that nonsense. The ampersand was doing something useful in Acorn filing systems over two decades ago. (nerr!)
The '&' not only restores your rightful user directory, it also restores your rightful access to the files that are rightfully yours. Righteous!