|
www.riscos.com Technical Support: |
There are a number of differences between the UNIX and RISC OS models of a filing system, the more important being:
Because of these clashes changes have to be made when mapping RISC OS file names and attributes to UNIX ones, and vice versa. Generally the changes made when mapping one way are reversed when mapping the other way, so the system is as transparent as possible if only viewed from RISC OS. If you view the files using the remote filestore though, you'll notice some differences.
This chapter outlines how the mapping of file names takes place, and what differences you'll notice between the RISC OS view of a file and the UNIX view.
This section describes how RISC OS NFS maps files from RISC OS to UNIX.
Character translation
The first change RISC OS NFS makes to a filename is to translate the character `/' (the UNIX directory separator) to `.', for example:
| RISC OS name | UNIX name |
| fred/c | fred.c |
| /profile | .profile |
File type extensions
RISC OS NFS then adds a filename extension to store the RISC OS file type.
You can set the extension used for any given file type to one of your choice. To do so you must edit the extensions file, held within the Internet application. See the section Editing the extensions file.
If you haven't set up a filename extension for a given file type,
then a default extension gets used instead. The default mapping
of a RISC OS file called Fred is as follows:
| RISC OS type | UNIX name | Notes |
| Text | Fred | |
| UNIX Ex | Fred | |
| Draw (&AFF) | Fred,aff | |
| Obey (&FEB) | Fred,feb | and other file types similarly… |
| dead † | Fred,xxx | |
| untyped | Fred,lxa | |
| directory | Fred |
† A dead file is one that has been created but the contents of which are being updated. For example when NetFS copies a file to a file server it reserves space by creating a dead file before writing to it.
The contents of files are unchanged when transferring to UNIX, save for untyped files. These have their load and execute addresses appended to the file, making it 8 bytes longer:
The RISC OS file ended before L0, while the UNIX file ended after E3
L0 is the least significant byte of the load address, L3 the most significant. Bytes E0 to E3 are the execute address.
When creating a new file or directory
You can use the system variable NFS$CreateAccess to define the default read/write access attributes for user, group and other that RISC OS NFS sets when creating a file or directory on UNIX. This variable uses six of its lowest nine bits:
You can set it in octal by using a leading `0' (you'll find this familiar if you've ever used the UNIX chmod command with numbers), or in hexadecimal by using a leading `0x', or in decimal by just using a number. So the following would all set the variable to specify user read/write access, group read only access, and no access to others:
*Set NFS$CreateAccess 0640 (using octal)
*Set NFS$CreateAccess 0x1A0 (using hexadecimal)
*Set NFS$CreateAccess 416 (using decimal)
You can override the value of the NFS$CreateAccess variable for a specific mount by setting a system variable NFS$CreateAccess_mountname .
You should set these access variables in a boot file; see your RISC OS 3 User Guide if you need help on this.
If a relevant access variable exists then files and directories are created with the read/write access it specifies. Files of type UNIX Ex also have their execute attributes set to be the same as the corresponding read bits in the variable.
If no relevant access variable exists then files are created with user read/write access, and with user execute permission if the files' type is UNIX Ex. Directories are created with user read, write and execute permission.
When mapped from RISC OS
When RISC OS NFS sets the access to a UNIX file using RISC OS attributes they are mapped as follows:
| RISC OS bit | UNIX bit |
| owner read | user read user execute is also set if owner read is set and the file's type is UNIX Ex |
| owner write | user write |
| public read | group read and other read group execute and other execute are also both set if public read is set and the file's type is UNIX Ex. |
| public write | group write and other write |
| locked | (discarded) |
Similarly, when RISC OS NFS sets the access to a UNIX directory using RISC OS attributes they are mapped as follows:
| RISC OS bit | UNIX bit |
| owner read | ignored - i.e. user read is left unchanged |
| owner write | ignored - i.e. user write is left unchanged user execute is always set |
| public read | group read and other read |
| public write | group write and other read |
| locked | NOT group execute and NOT other execute |
UNIX date stamps any files just as usual if you use RISC OS NFS to create or amend them.
When RISC OS NFS is finding an object it searches in this order, using the first match it makes:
This section describes how RISC OS NFS maps files from UNIX to RISC OS.
File type extensions
The first change RISC OS NFS makes is to remove any filename extension used to store the RISC OS file type.
It starts by looking through the extensions file to see if the filename has an extension that matches one you specified; if so, the extension gets removed. You can in fact set up a different mapping for each direction of file transfer, so you can map many UNIX file extensions to single RISC OS file types. See the section Editing the extensions file.
If RISC OS NFS can't find a matching filename extension in the extensions file it then tries to remove any of its own default extensions; so the following all appear as Fred under RISC OS:
| UNIX name | Notes |
| Fred | |
| Fred,hhh | hhh is 3 lower-case hex digits |
| Fred,xxx | |
| Fred,lxa |
Truncation
The next thing RISC OS NFS does to a filename is to truncate it to the length set by the system variable NFS$TruncateLength. By default this is set to the value 10 - the same length as the maximum that the desktop Filers can handle. It only gets read once, when the NFS module is loaded.
If you want a different truncate length use the *Set command, say in a boot file:
*Set NFS$TruncateLength 12
If you're using NFS from the command line you may want to override filename truncation. To do so set the variable to a large number, e.g. 1000000.
The final change RISC OS NFS makes to a filename is to translate the character `.' (the Acorn directory separator) to `/', for example:
| UNIX name | RISC OS name |
| fred.c | fred/c |
| .profile | /profile |
RISC OS NFS makes the last 8 bytes of any file with a `,lxa' extension invisible; this is to hide the load and execute addresses it presumes itself to have appended.
If you generate a file in UNIX with a `,lxa' extension which is less than 8 bytes long, you will get unpredictable behaviour if you try to manipulate it from RISC OS.
When the access attributes of a UNIX file or directory get translated by RISC OS NFS they are mapped as follows:
| UNIX bit | RISC OS bit |
| user read | owner read |
| user write | owner write |
| user execute | (discarded) |
| group read | (discarded) |
| group write | (discarded) |
| group execute | (discarded) |
| other read | public read |
| other write | public write |
| other execute | (discarded for files)
NOT locked for directories |
RISC OS NFS always uses the UNIX last modified date stamp to map to a RISC OS date stamp. It assumes the UNIX date stamp to be in GMT, and uses the value set by *TimeOffset to convert this to local time. See *TimeOffset.
RISC OS NFS resolves file types by looking for any filename extension used to store the RISC OS file type. It does so at the same time as it resolves filenames - see also the earlier Filenamessection.
It starts by looking through the extensions file to see if the filename has an extension that matches one you specified; if so, it sets the file to the corresponding file type. See the section Editing the extensions file.
If RISC OS NFS can't find a matching filename extension in the
extensions file it then sets the file type using its default file
extensions. So, again taking the example of a file that will be
displayed as Fred:
| UNIX name | Notes | RISC OS type |
| Fred | UNIX directory | Directory |
| Fred | no execute bit is set | Text |
| Fred | any execute bit is set | UNIX Ex |
| Fred,hhh | hhh is 3 lower case hex digits | &hhh |
| Fred,xxx | dead | |
| Fred,lxa | none, undated |
See also the section Soft links.
If a UNIX file has the extension `,lxa' then RISC OS NFS assumes it to be a RISC OS untyped file that it created on UNIX. It uses the last 8 bytes of the file to give the load and execute addresses. So if they were:
(The RISC OS file ends before 67, while the UNIX file ends after 89.)
the load address would be &01234567, and the execute address would be &89ABCDEF.
RISC OS NFS resolves soft links up to eight times - that is, whilst following a soft link, it only allows eight soft links to be traversed. If this traversal reaches an existing object other than a soft link:
In other words soft links behave transparently except that, where there is more than one soft link to a file, its type may differ depending on which soft link you use to view it.
RISC OS NFS can't traverse a soft link that leaves a mount. If a UNIX link name starts with the character `/' then RISC OS NFS treats it as the root of its mount. Consequently absolute soft links will only work if you've mounted the UNIX root directory `/' and if the soft link does not leave the root filing system. For example, if you had mounted /usr then this UNIX soft link in the /usr directory would be traversed:
lrwxrwxrwx 1 root wheel 11 Feb 23 17:19 man -> ./share/man
whereas this one wouldn't be:
lrwxrwxrwx 1 root wheel 11 Feb 23 17:19 man -> /usr/share/man
We advise that when you make soft links on UNIX you always make relative links (i.e. start them with `.' or `..') rather than absolute ones.
If a soft link does not resolve to an existing non-soft-link object within eight expansions it's displayed as a file with type `SoftLink' (&FDC). You can't do anything from RISC OS with one of these dead soft links.
Block and character special files and named sockets are displayed as UNIX Ex files. Fiddle with these from RISC OS at your peril!
The extensions file is held in the files subdirectory of the Internet application, and configures the mapping of RISC OS file types to UNIX filename extensions. To add your own filename extensions for specific RISC OS file types you need to edit this file:
RISC_OS_file_type new_extension [anything]
The RISC OS file type can be the name of a file type, or its file type number in hexadecimal. So to give Data files (type &FFD) the extension `.dat' you could use either of these lines:
Data .dat
ffd .dat
When moving to UNIX the extension is only added if it's not already present. So if the line were to read:
ffd .dat sticky
the Data file output would be renamed output.dat , whereas the Data file output.dat would not be renamed.
When returning from UNIX the extension doesn't get removed; otherwise it's handled the same as ever, so the file type gets set using this extension.
We expect you'll want the `To extensions:' part to duplicate the entries in the `From extensions' part, so any extension that gets added when a file is transferred to UNIX gets removed again if the file returns to RISC OS. However, there may be a lot of UNIX extensions that you wish to convert to a single RISC OS file type. For example, you may have several UNIX applications each of which generates text files with different extensions - say `.txt', `.doc' and `-asc'. To do so, just add extra entries to the `To extensions', thus:
Text .txt
Text .doc
Text -asc
When you've added all the extensions you want to, save the edited extensions file, overwriting the old one.