03/13/84 canonicalize_mailbox Syntax: canonicalize_mailbox path {-control_args} Function: converts the messages in a mailbox into their canonical form as defined by the MR10.2 mail system. Arguments: path is the pathname of the mailbox whose messages are to be converted. The suffix "mbx" is supplied if needed. The star convention is accepted. Control arguments: -force, -fc temporarily alters your access to the mailbox when necessary to convert the messages in the mailbox (see "Access required" below). -no_force, -nfc never alters your access to the mailbox. (Default) -privilege, -priv uses privileges to bypass the restrictions on the canonicalization process introduced by the Access Isolation Mechanism (see "Notes on AIM" below). -no_privilege, -npriv does not use privileges. (Default) Access required: You must have status (s), modify (m), and append (a) access to the directory containing the mailbox. In addition, if -force is not specified, you must have read (r), add (a), and delete (d) extended access to the mailbox itself. If -privilege is specified, you must have execute (e) access to the system_privilege_ gate and your maximum process authorization must be system_high. Notes: The canonical form of a message is similar to the text of the printed representation of that message when formatted using the default formatting modes. For a description of the canonical form, type help message_format.gi -section canonical form Messages stored in mailboxes prior to MR10.2 were not stored in their canonical form. Unless these messages are converted to their canonical form, subsystems, such as read_mail, that provide the option to select message by content are required to format the messages during the search. This formatting while searching severely affects the performance of the selection process. Messages stored in a mailbox after the installation of MR10.2 are stored in canonical form and will not affect the performance of context searches. This command needs to be used only once on any given mailbox. It is especially recommended that this command be used on any large mailbox (e.g., logboxes or saveboxes containing more than fifty messages). This command first creates a new mailbox in the same directory as the mailbox whose messages are to be converted. The messages are then read from the original message, canonicalized, and stored in the new mailbox. Next, the names, access control list, maximum length, and safety switch setting of the original mailbox are moved to the new mailbox. Finally, the original mailbox is deleted. If the directory containing the original mailbox has insufficient quota for the new mailbox, the original mailbox is left intact and an error message is printed. The record of any process accepting messages on the original mailbox is lost during the canonicalization process. You must reissue the accept_messages command, if needed, for each mailbox that is processed by canonicalize_mailbox. Due to the nature of the accept_messages command, the explicit pathname of your default mailbox (>udd>Project_id>Person_id>Person_id.mbx) must be supplied if that mailbox is canonicalized in order to reaccept messages. After a mailbox has been canonicalized, all messages in the mailbox are owned by the user who issued the canonicalize_mailbox command. If you originally placed a message in the mailbox, you cannot delete it if you have own (o) extended access on the mailbox. Normally, this side effect of canonicalization is invisible for logboxes and saveboxes as only the creator of the logbox or savebox has access on that mailbox. Notes on AIM: If the Access Isolation Mechanism (AIM) is in force at a site, several restrictions are placed on the use of canonicalize_mailbox. These restrictions are eliminated through the use of -privilege provided that you have sufficient access to use that control argument (see "Access required" above). To use canonicalize_mailbox, your process authorization must be equal to the access class of the directory containing the mailbox whose messages are to be converted. Unlike ordinary segments, the access class of a mailbox may be greater than the access class of its containing directory. Each message in a mailbox has its own access class; the access class of the mailbox specifies the maximum access class for any message that may be added to the mailbox. If the access class of a mailbox is greater than your process authorization, it may contain messages that you can not read. If you were to canonicalize that mailbox, any such messages would be lost. Therefore, the canonicalize_mailbox command queries for permission to continue if asked to process a mailbox whose access class is greater than the process authorization. Unless you are quite certain that there are no upgraded messages in the mailbox, you should answer "no" to this query and ask a system administrator to canonicalize the mailbox using -privilege. The canonicalized mailbox created by this command has an access class equal to your maximum process authorization. If this access class is less than the previous acess class of the mailbox, a warning is issued. If the new access class is insufficient (e.g., a mailbox shared by several users with different maximum authorizations), ask a system administrator to reclassify the mailbox via the reclassify_sys_seg command. ----------------------------------------------------------- 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