! (New) File system communication message formats and codes. This is the ! internal standard way of transmitting requests between internal & external ! file system clients and internal & external file servers. ! Filesystem mailbox names. %conststring(31) local file system mailbox = "FILESYSTEM:LOCAL" %conststring(31) special file system mailbox = "FILESYSTEM:SPECIAL" %conststring(31) FAP file system mailbox = "FILESYSTEM:FAP" %conststring(31) H2 file system mailbox = "FILESYSTEM:H2" %conststring(31) NFS file system mailbox = "FILESYSTEM:NFS" ! Standard message format. %recordformat fs message fm(%record(message fm) system header, %integer fsys work, %record(mailbox fm)%name followup mailbox, %integer access token, %integer tag, %integer request, %integer request flags, response flags, %integer status, error code, %string(*)%name textual response, %record(*)%name filename, %integer components translated, %record(*)%name filename 2, %integer components translated 2, %integer file token, %integer mode, compatible mode, %integer block size, %integer byte offset, byte count, %bytename data buffer, %record(*)%name file attributes, %string(*)%name textual data, %integer request specific, %string(*)%name textual data2) ! Request codes are subdivided into two 16-bit parts: the high-order bits ! identify the particular filesystem for which the code is meaningful, while ! the low-order bits identify the particular operation. Bit-15, if set, ! indicates that the request contains a filename in the "usual place" and that ! the file system module should attempt to translate it as far as possible ! even thought the actual operation is itself not understood -- this allows ! non-standard operations to name files through the standard filesystem ! mechanisms. Note that interpreters should not expect that this bit will ! necessarily be set for standard request codes. Not all fields need be ! used for any particular request; variant records were deliberately avoided ! in order not to pre-judge the formats of non-standard requests. %constinteger filesystem mask = 16_0FFF0000 %constinteger request mask = 16_00000FFF %constinteger interpret filename = 16_00008000 ! The request flags field should always be valid: zero is the preferred default, ! meaning that there are no flags specified. Most flag values are request- ! specific; the following, however, are universal: %constinteger non local flag = 16_00010000; ! User is not co-resident ! Standard requests (filesystem 0) %constinteger interpret filename request = 16_00008000 ! This request asks that the path be examined to check the validity of the ! filename and the existence (if any) of the file. The only guaranteed ! result is success or an appropriate error status. There is one request ! flag, viz to ask that translation stop at the penultimate filename. %constinteger stop at penultimate = 1 %constinteger open file request = 16_00008001 ! Open takes a filename, together with the requested mode and the compatible ! mode, and returns a file token and block size. The file system module is ! expected to supply the address of a followup mailbox, to which subsequent ! reads, writes and closes will be directed, and a blocksize for the user's ! runtime support buffer management. ! Open/compatible modes are coded as follows: %constinteger read file mode = 16_0001 %constinteger modify file mode = 16_0002 %constinteger append to file mode = 16_0004 ! The following additional compatible modes can be specified: %constinteger exchange file mode = 16_0008 %constinteger link file mode = 16_0010 ! The filesystem is not obliged to honour any compatible mode request exactly, ! but will guarantee that the compatibility constraints will be at least as ! strong as those requested. Any unsatisfiable requests will be rejected. ! The following request flags can be specified: %constinteger create if flag = 16_0001 %constinteger create flag = 16_0002 %constinteger temporary flag = 16_0004 %constinteger unique name flag = 16_0008 %constinteger no inherit flag = 16_0010 %constinteger close file request = 16_00000002 ! Close requires that the token obtained from the open request be supplied. ! Requests will be directed to the followup mailbox supplied in the open ! response. There will eventually be at least two request flags, viz truncate ! and improper close. %constinteger auto truncate flag = 1 %constinteger improper close flag = 2 %constinteger read data request = 16_00000003 %constinteger write data request = 16_00000004 ! These two require that the file token be specified, together with the byte ! offset and byte count and the address of the first byte of the buffer. ! The maximal amount to be transferred is specified for the call, the actual ! amount being returned. Note that the two need not necessarily be the same. ! Filesystems are not obliged to accept transfers on other than the block ! boundary they specified in response to the open request. %constinteger truncate file request = 16_00000005 ! Truncate operates on open files, specified by token. The new size is ! specified in the byte count field. Requests will be directed to the followup ! mailbox. %constinteger make accessible request = 16_00008006 ! The file to be made accessible is specified by filename. This operation is ! provided to "unlock" files which are inaccessible as a result of having been ! improperly closed. %constinteger create directory request = 16_00008007 ! The directory is specified by name. There is also a local specific version ! of this request which takes a partition number in the request specific field. %constinteger remove file request = 16_00008008 ! The file to be removed is specified by filename. %constinteger zap full directory flag = 16_8000 %constinteger rename file request = 16_00008009 ! The two files to be renamed are specified by filename and filename2. The ! filesystem module should assume that both filenames have been verified to ! "belong to" it -- cross-filesystem rename attempts will be rejected by the ! user's runtime support at a previous stage. The filesystem may, of course, ! apply stricter constraints at its discretion. ! The next two are in until such time as we think up a standard way to ! specify the information (i.e. probably permanently). As different ! filesystems have different protection conventions, it is easiest to use ! a free textual form and put the onus on the file system module to parse it ! and reject anything it doesn't understand. %constinteger textual file attributes request = 16_0000800A ! This takes a filename, and returns protection, datestamp and file size ! information as textual data, separated by one or more spaces. %constinteger textual permit file request = 16_0000800B ! This takes a filename, and protection in textual data. The exact form of the ! protection specifier is file system specific (unfortunately). %constinteger last standard request = 16_000B ! Local filesystem requests (filesystem 1) %constinteger local request = 16_00010000 %constinteger local insert textual translation request = 16_00018001 ! This specifies the name by filename and the translation by textual data. ! The translation level is in mode. For translations which redirect to a ! different filesystem, the exact form of the translation data depends on ! that filesystem; however the first component always specifies the name ! of the filesystem. %constinteger local get file header request = 16_00018003 ! The file is specified by filename, with the buffer specified by data buffer. %constinteger local create directory request = 16_00018004 ! This is much the same as the standard create directory request, except ! that the partition number is specified in the request specific field. ! The local filesystem will default the partition to that of the parent ! directory for the standard request. %constinteger local obtain attributes request = 16_00018005 %constinteger local modify attributes request = 16_00018006 ! These two take a filename and an attributes list. They allow access to ! attributes which are not available via the standard textual requests. %constinteger local reload admin data request = 16_00010007 ! This request asks the local filesystem manager to reload its username/user-ID ! translation database, allowing users to be added/removed and their various ! privileges and groups modified. The request is likely to be removed again ! at some later date. Privilege is required to issue it. %constinteger local enquire nth entry request = 16_00018008 ! This is a nasty hack, and is only in for the benefit of the old-style ! filestore-protocol interpreter. The request asks that the name of the ! nth entry (specified in request specific) in the directory is returned ! in textual data. %constinteger local insert ID request = 16_00018009 ! Inserts the file ID, specified in "request specific" in the named directory. %constinteger last local request = 16_0009 ! New-style file access protocol remote filesystem (filesystem 2) %constinteger fap request = 16_00020000 ! Old-style 1976-protocol remote filesystem (filesystem 3) %constinteger old style request = 16_00030000 %constinteger old logon request = 16_00030001 %constinteger old logoff request = 16_00030002 %constinteger old quote request = 16_00030003 ! The old protocol requires each user explicitly to log on and off the ! filestore. These requests allow the appropriate context to be established ! modified, and broken. %constinteger old copy file request = 16_00038004 ! This request asks that the remote filestore perform a file copy on behalf ! of the local client. The files are specified in filename and filename2. %constinteger old set pass request = 16_00030005 ! Change the user's password, specified in textual data. %constinteger last old request = 16_0005 ! NFS filesystem (filesystem 4) %constinteger NFS request = 16_00040000 %end %of %file