02/27/85 retrieve Syntax as a command: retrieve path {-control_args} Function: retrieves specified storage system segments, directories and subtrees. It does this by copying them from a hierarchy dump tape into the hierarchy, possibly into different places in the hierarchy than those from which they were originally dumped. The retireve command calls the backup_load command to do the actual retrieving. The retrieve command requires a retrieval control file, containing the pathnames of the objects to be retrieved. It calls backup_load once for each line in the control file. See "Notes on Format of a Retrieval Control File" below. Cross retrievals are allowed; i.e., objects can be retrieved into different places in the hierarchy than those specified on the dump tape. The retrieve command places its maps in the working directory and doesn't automatically dprint them. Quota on the retrieved directories is not force-set. The retrieve command is one of the commands used for hierarchy reloading and retrieving of storage system segments and directories. The other commands are: backup_load reload (initializer command) reload (Multics command) reload_system_release You should note that argument processing for all of the hierarchy backup commands is performed by a common argument processing procedure. The values of all arguments are remembered in static storage and remain in effect for the life of the process, unless changed by arguments given in subsequent invocations of backup commands. It should also be noted that the dumping commands and the reloading/retrieving commands are all part of the same hierarchy backup system, and argument values set by the dumping commands remain in effect for the reloading/retrieving commands and vice versa, unless overridden. However, dumping and reloading cannot be done in the same process; use the new_proc command between dumping and reloading. See "Notes on Default Arguments" below. Arguments: path is the absolute pathname of a retrieval control file (see "Notes on Format of a Retrieval Control File" below). This argument is required. It can be given anywhere on the command line. Control arguments: -all causes segments to be retrieved from the tape regardless of their date/time dumped. This is the default. This control argument overrides a previously given DATE argument. -brief_map, -bfmap creates a map file that lists the processed entires. -control path indicates that path is a hierarchy retrieval control file pathname. See "Notes on Format of a Retrieval Control File" below. -debug disables those hphcs_ calls that set quotas and transparency switches. -destination STR, -ds STR specifies a destination for printing maps and error file. The default is "incremental" for maps and "error file" for error files. -error_of writes error messages into a file rather than printing them. The name of the error file is printed when the first error is encountered. This is the default. -error_on writes error messages on the user's terminal. -first prevents searching a tape for additional copies of a requested segment or subtree after the first copy has been retrieved. -header STR, -he STR specifies a heading for printing maps and error files. -last indicates that the last copy of a given segment or subtree on a tape or set of tapes is to be retrieved. This is the default. -map writes a list of the segments and directories processed into a file. This is the default. -nodebug enables hphcs_ calls to set quotas and the transparency switches. This is the default. -nomap inhibits listing of the names of processed segments and directories. -noprimary, -npri uses each pathname as given. The default is -primary. -noqcheck causes the hierarchy reload to be done with quota checking suspended. Access to hphcs_ is required. This is the default. -noquota inhibits resetting of quotas. See -quota. This is the default. -noreload inhibits actual hierarchy reloading of segments into the hierarchy. This control argument can be used with -map to create a table of contents of the tape. The -noreload control argument also causes the names that would have been reloaded to be put into the map. -nosetlvid inhibits the setting of the logical volume identifiers for each directory to be reloaded. -notrim inhibits deletion of entries in a directory. Entries can only be added or modified. This is the default. -operator STR indicates that STR is the user's name or initials (up to 16 characters in length). -primary, -pri replaces all directory names in each pathname with the primary names. This is the default. -pvname STR indicates that segments and directories can only be retrieved onto the physical volume specified by STR. -qcheck causes quota restrictions to be enforced during the reload. -quota causes the quotas on directories being reloaded to be set to the values they had when the directories were dumped. Access to hphcs_ is required. -reload enables actual reloading of segments into the hierarchy. This is the default. -request_type STR, -rqt STR specifies an output request type for printing maps and error files. Available request types can be listed by using the print_request_types command (described in the Multics Commands and Active Functions manual, Order No. AG92 ). The default is "printer". -setlvid enables setting of the logical volume identifier for reloaded entries inferior to each directory reloaded. This is the default. -trim enables deletion of all entries in a directory not found in the copy of that directory being reloaded. This causes entries deleted from an earlier version of the directory to be deleted when a later version is reloaded. It has effect only in the case of a directory that is both on the tape and in the hierarchy. This is the default. DATE an argument beginning with a character other than "-", or ">" is assumed to be a date in a format acceptable to the convert_date_to_binary_ subroutine. If it can be converted successfully, then the hierarchy retriever only retrieves segments and directories dumped at or after the given date/time. Notes on default arguments: The values of arguments given to any of the hierarchy backup commands are remembered in static storage and remain in effect for the life of the process, unless explicitly changed during the invocation of a subsequent backup command. The following defaults are in effect for the reloader and retriever before any backup commands are given; they are not, however, reset to these values at the start of each backup command, except as noted below. -all -noquota -error_of -primary -map -reload -nodebug -setlvid -nohold -trim The following defaults are set automatically at the time the respective commands are executed: reload (initializer command), reload (Multics command), reload_system_release: -quota -trim retrieve: -all -noquota -notrim All of the above commands: -map Notes on format of a retrieval control file: The hierarchy retrieval is controlled by an ASCII segment containing one line for each object to be retrieved. A line can contain a single pathname or two pathnames separated by an equal sign. The left-hand side specifies the segment or directory sought and the right-hand side, if present, specifies the new name under which that entity is to be retrieved. The sought pathname must begin with a > and end with either an entryname or the characters >**. If an entryname is specified, a single object of that name is retrieved. If >** is specified, the entire directory hierarchy, beginning at the point indicated in the pathname, is retrieved. In this case, the right_hand pathname, if present, ends in the name of the directory under which these entries are to be reloaded. For example: >udd>one_dir>**=>udd>two_dir If a new name is specified on the right, it can be either a pathname or an entryname. If an entryname is given, the single object found is loaded with its former pathname and the new entryname. If two pathnames are specified, both are checked against the current hierarchy and a new pathname consisting only of the primary entryname is created. This new pathname, as well as the original, is then used in searching the hierarchy. For example, >udd>sd is translated into >user_dir_dir>SysDaemon and both versions are sought. Primary names are used unless the -noprimary control argument is in effect. A hierarchy retrieval control file can contain a maximum of 256 lines. ----------------------------------------------------------- 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