File mapping from RISC OS NFS to UNIX:

When RISC OS NFS is enumerating a directory the objects are displayed as follows:
---------------------------------------------------------------------------------

All objects, due to the clash between RISC OS and NFS servers about what is
a directory separator, have any .s in their names translated to /s. Due to
the special significance of . and .. to UNIX NFS servers these are not
displayed on the RISC OS side.


Regular files:

Files with suffix ,xxx have load and execute addresses set to &deaddead. The
name displayed is the source name without the ,xxx suffix. eg fred,xxx would
be displayed as fred with load and execute addresses of &deaddead. The
contents of this sort of file appear to be the same when viewed from the
UNIX and the RISC OS side.

Files with suffix ,lxa have load and execute addresses set to the last 8
bytes of the UNIX file. If one was reading the UNIX file and labeled the
last 8 bytes L0 L1 L2 L3 E0 E1 E2 E3 in that order as read sequentially from
beginning to end, the L0 would the least significant byte of the load
address, L3 the most significant and E0 to E3 would be the execute address.
So, for example, if the UNIX file fred,lxa had the last 8 bytes 01 23 45 67
89 ab cd ef (all in hex), then the load and execute addresses would be
&67452301 and &efcdab89. In other words, the load and execute addresses are
stored little-endian. The name of this sort of file is displayed with the
,lxa suffix removed. So, for example, fred,lxa would be displayed as fred.
The contents of this sort of file appear different when viewed from the UNIX
and RISC OS side. When viewed from the RISC OS side the last eight bytes are
invisible, that is, the file appears to be eight bytes short of the UNIX
size. Files generated from UNIX with a ,lxa suffix which are shorter than 8
bytes in UNIX will cause unpredictable things to happen when manipulated
from RISC OS.

Files with suffix ,HHH where HHH is three lower case hex digits are treated
as typed and dated RISC OS files. The type of the RISC OS file is &HHH and
the date is taken from the UNIX file's date last modified. The ,HHH suffix
is stripped before the name is presented to RISC OS. So, a file called
fred,ffd would be displayed as fred and would have the type 'Data'
(the file type 'Data' is number &ffd). The contents of this sort of file are
the same when viewed from RISC OS and UNIX.

Files without a suffix of the above form are displayed with the same name as
stored on the server. If they have any of their execute bits set, then the
file's type will be UNIX Ex (short for UNIX Executable), otherwise they will
be displayed as Text files. The contents of these files are the same when
viewed from RISC OS and the server.


Directories:

Directories have the same name when viewed from RISC OS and the server.


Soft Links:

Soft links will be resolved up to 8 times. That is, whilst following a soft
link, RISC OS NFS will allow only 8 soft links to be traversed. If a soft
link successfully ends up at an existing object other than a soft link, then
it will be this object's UNIX attributes and contents which will be used.
For determination of suffix it is the soft link's NFS name which is used. In
other words, soft links behave transparently, except that, where there is
more than one soft link to a file, the file's type may be different
depending which soft link is used to view that file. If the soft link does
not resolve to an existing non-soft-link object within 8 expansions then it
will be displayed as a file with type 'SoftLink' (&FDC). It is not possible
to do anything with a dead soft link from RISC OS.


Other object types:

Block and character special files and names sockets are displayed as UNIX Ex
files. Fiddle with these from RISC OS at your peril!


Summary:

All these files are displayed as 'fred' in RISC OS:

UNIX Name       Meaning
fred            File is either text or UNIX Ex or dead soft link (any x mode bit set causes UNIX Ex, otherwise text).
fred,hhh        File has file type hhh (hexadecimal).
fred,xxx        File is dead (load = exec = 0xdeaddead).
fred,lxa        File is undated, load and exec obtained from end of file.


A . occuring in the name is translated to a /, so that:

UNIX Name       RISC OS Name
fred.c          fred/c
.profile        /profile

The case of a file name is transfered through to RISC OS:

UNIX Name       RISC OS Name
Fred            Fred
fred,lxa        fred
FRED,hhh        FRED


When RISC OS NFS is finding an object
-------------------------------------

When an object is wished to be found the following order of search is made. The
first matching condition determins which UNIX file is accessed.

1) A straight lookup is made, ie an exact name match is made.
2) The directory is enumerated and the first file which, after any RISC OS specific
        suffix has been removed, matches exactly the name required.
3) The directory is enumerated and the first file which, after any RISC OS specific
        suffix has been removed, matches disregarding the case of the letters.



When RISC OS NFS is creating a regular file
-------------------------------------------

All these examples assume the RISC OS name of the file is Fred
Type            UNIX File
Text            Fred, non executable
UNIX Ex         Fred, executable for user and executable where readable
dead            Fred,xxx non executable
&abc            Fred,abc non executable
untyped         Fred,lxa with load and execute address appended to file

All characters are transfered to UNIX unchanged, except for / which is
translated to ., for example:

RISC OS Name    UNIX Name
fred/c          fred.c
/profile        .profile


When RISC OS NFS is translating the access attributes of a file
---------------------------------------------------------------

From UNIX to RISC OS
UNIX Bit        RISC OS bit
user read       owner read
user write      owner write
user execute    This is reflected in the file's type if there is no RISC OS specific suffix.
                        If there is a suffix, then this bit is discarded.
group read      Discarded
group write     Discarded
group execute   As for user execute
other read      Public read
other write     Public write
other execute   As for user execute

From RISC OS to UNIX

When creating files, the number contained in system variable
NFS$CreateAccess gives the read/write access attributes for user/group and
other. If this variable does not exist, then the access is owner read and
write. When changing the access to a file this applies:

RISC OS bit     UNIX bit
owner read      user read
owner write     user write
public read     other read and group read
public write    other write and group write
locked          Discarded
                user execute set if user read is set and the file has a file type which is UNIX Ex
                group execute is set if public read is set and the file is typed with file type UNIX Ex.
                public execute is set if public read is set and the file is typed with file type UNIX Ex.

When translating the access attributes of a directory:

When creating directories, the number contained in system variable
NFS$CreateAccess gives the read/write access attributes for user/group and
other. If this variable does not exist, then the access is set to owner
read, write and execute. When a directory's access is changed:

From UNIX to RISC OS
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   ~locked

From RISC OS to UNIX
RISC OS bit     UNIX bit
owner read      <left unchanged>
owner write     <left unchanged>
                user execute set
public read     other read and group read
public write    other write and group read
locked          ~other execute and ~group execute




All activities not defined above do not have what they do defined. Some of
them may be considered a bug, some may not, but all of them may cause loss
of data, so fiddle with care!

