01/29/86 extended_entries.gi An extended entry is a storage system entity that is created and manipulated by a particular subsystem and for which the operations performed by the standard file system commands and subroutines are either incorrect or impossible. For example, the mailbox is created and maintained by the message segment facility. All mailboxes must be named with the suffix ".mbx" and their accessibility is defined by extended modes instead of the more familiar "rew" or "sma" modes. In addition, proper access to these entries is enforced by the fact that they are ring 1 residents: they are inaccessible from the user ring unless message_segment software (ring 1 resident) is invoked through a gate. Extended entry software allows the standard Multics commands and subroutines to operate upon extended entries without compromising the integrity of the owning subsystem. This applies not only to bundled extended entries, such as mailboxes and message segments, but also to user-written subsystems. A number of commands and subroutines have been modified to handle correctly extended entries. These include add_name, copy, copy_acl, copy_dir, copy_names, delete, delete_acl, delete_name, list_acl, move, move_dir, rename, set_acl, set_max_length, set_ring_brackets, status, switch_on, switch_off, copy_, copy_dir_, copy_acl_, copy_names_, delete_, dl_handler_, nd_handler_. There are two new commands for printing information about extended entries. The list_entry_types command prints a list of all the entry types that you can find in the search rules. It provides only the name of the entry type and the suffix it uses. For detailed information about an entry type, use describe_entry_type. It prints out the name of the type, various attributes, and the pathname of an info segment containing more information about the entry type. The status commands now accepts a -type control argument, which prints the type of a storage system entry, be it extended (as for mailboxes) or standard (segment, directory, etc.). The extended entry facility is implemented by the fs_util_ subroutine. The entry points in fs_util_ are used to change and retrieve information about any file system entry. The fs_util_ subroutine determines whether or not the entry is extended by examining its suffix. Assuming that the suffix is XXX, fs_util_ attempts to locate and then invoke a subroutine named "suffix_XXX_$validate". If both of these actions succeed, the entry is considered to be extended and subsequently referenced through suffix_XXX_; otherwise it is considered standard, and fs_util_ decides how to reference it. To enable an application program to operate upon extended entries, the hcs_ calls it makes to perform file system operations should be replaced by the corresponding fs_util_ calls. Calls to any one of the standard system subroutines listed above, which already support extended entries, need not be changed. To implement an extended entry type, you must choose a suffix and implement a suffix support routine for that entry type. Each suffix support routine must support the suffix_info and validate entrypoints, as well as a few optional ones. These routines are called by fs_util_. If any of the optional entry points are not provided, fs_util_ returns an error code of error_table_$unsupported_operation to its caller and the particular operation fails. There are two restrictions in implementing an extended entry type. First, an extended entry type can use only standard entry types, i.e., segment, directory, multisegment_file, and dm_file, as the underlying storage type. Second, if the acl modes for the extended entry type do not map directly onto the standard modes, then they must be stored in the extended modes field of hte underlying type. For example: mailboxes use the extended modes field of segments to store their modes of "adroswu". ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved