10/10/88 enter_imft_request, eir Syntax as a command: eir transfer_specs {-control_args} Function: submits requests to transfer files or subtrees to or from remote Multics systems using the Inter-Multics File Transfer (IMFT) facility. Arguments (transfer_specs): The transfer_specs specify the files or subtree to be transferred and has the following format: path {-target_pathname equal_path}, path {-tpn equal_path} path specifies the relative pathname of files and/or subtrees to be transferred. The star convention is accepted. This is also referred to as the source pathname. If supplied, the equal_path is the relative pathname of where the files and subtrees will be placed on the target system. The equal convention is accepted. The target pathname is converted to an absolute pathname relative to the working directory on the local system. If not given, the files and subtrees are given the same pathname on the target system. Control arguments (object type selection): -file, -f specifies that transfer requests should be issued only for files which match the transfer_specs. If a transfer_spec does not use the star convention and there is no matching file, an error message is issued. (Default -- issue requests for matching files and subtrees). -subtree, -subt specifies that transfer requests should be issued only for subtrees which match the transfer_specs. If a transfer_spec does not use the star convention and there is no matching subtree, an error message is issued. This is incompatible with the -extend and -update control arguments. The default is to issue requests for matching subtrees. Control arguments (file handling): -extend appends the contents of the source pathname to the end of the contents of the target pathname. An error occurs if the source is a nonfile. An error occurs if the target does not already exist. It is incompatible with the -subtree option. -replace, -rpl, -rp replaces the entire target file specified by the target pathname (deletes and creates a new object), rather than modifying its contents as is done by -extend and -update. (Default) -update, -ud replaces the contents of the file specified by the target pathname with those of the source pathname without deleting the target file or changing any of its attributes. An error occurs if the source is a nonfile. An error occurs if the target pathname does not already exist. It is incompatible with the -subtree option. Control arguments (directory handling): -merge_directories, -mdr specifies that if there is a directory on the target system with the same name as one of the names on the root directory of the subtree being transferred, the contents of the source subtree will be merged with the target subtree. If the target entry is not a directory, processing will continue as though -replace_directories had been specified. Any directories within the subtree are treated in a similar fashion with respect to name duplications. See the Notes for a description of the treatment of files within the subtree. (Default) -replace_directories, -rpdr specifies that if there is an entry on the target system with the same name as one of the names on the root directory of the subtree being transferred, that name will be removed from the target entry; if the target entry has only one name, it will be deleted. Control arguments (chase): -chase specifies that transfer requests should be issued for the targets of any links which match the transfer_specs. (Default -- chase links for any transfer_specs that do not use the star convention; do not chase links for any transfer_specs that use the star convention) -no_chase specifies that transfer requests are not issued for the targets of any links which match the transfer_specs. Control arguments (object selection): -date_time_after DT, -dtaf DT skips selected files and subtrees if their date_time_contents_modified value is older than the time selected by DT. This option is not applied to contents of subtrees. The DT string must be acceptable to the convert_date_to_binary_ subroutine. This option facilitates selecting only modified information to reduce IMFT traffic. The -dtaf option only applies to push transfers, ie, transfering objects from the local system to the remote. -skipped, -skpd turns on the display of the objects that are skipped when the -date_time_after option is used. -no_skipped, -nskpd turns off the display of the items that are skipped when the date_time_after option is used. (Default) Control arguments (delete): -delete, -dl deletes the source pathname immediately after it is successfully transferred. -no_delete, -ndl does not delete objects. (Default) Control arguments (direction): -destination STR, -ds STR identifies the remote system to which the files and subtrees are to be transferred. STR must be one of the names listed by the print_imft_sites command. -source STR, -sc STR identifies the remote system from which the files and subtrees are to be transferred. STR must be one of the names listed by the print_imft_sites command. If neither -destination nor -source is specified, the default is -destination imft. -queue N, -q N specifies that the requests be entered in priority queue N where N is an integer between 1 and 4 inclusive. (Default -- depends on the destination or source specified) Control arguments (notification): -notify, -nt sends notification of successful initiation and completion of each transfer request. The notifications are sent on the the local and remote systems. (Default) -no_notify, -nnt suppresses notifications of successful transfer on both systems. Any errors detected during transmission will still cause mail to be sent regardless of the use of -no_notify. Control arguments (display): -brief, -bf suppresses the messages providing the request IDs of the requests entered by this command. -long, -lg prints the messages providing the request IDs of the requests entered by this command. (Default) -long_id, -lgid prints the long form of the request ID in any messages. -short_id, -shid prints the short form of the request ID. (Default) -absolute_pathname, -absp prints the absolute pathname of the file or subtree along with the request ID for each request entered by this command. -entryname, -etnm prints only the entry name of the file or subtree along with the request ID for each request entered by this command. (Default) Control arguments (misc): -foreign_user Person.Project, -fu Person.Project specifies the identity of the user at the remote system on whose behalf the transfer requests are being entered. Notifications on the remote system are sent to this user. See "Access required" below for further information. (Default -- the same as the user on the local system) Access required: All access checking is done using explicit ACL entries. An explicit ACL entry has an access name of the form "Person.Project.*". ACL entries which have access names of "Person.*.*", "*.Project.*", or "*.*.*" will not work. In order to check the access of any object, the daemon must have at least (ie, it does not have to be explicit) "s" access to the containing directory. In order to transfer a file or subtree from the source system to the target system, the following conditions must be met: For files, the user on the source system must have explicit "r" access to the file; for subtrees, the user must have explicit "s" access to the root of the subtree and each directory contained therein and explicit "r" access to each file in the subtree. The user must also have explicit "s" access to the containing directory of the object specified by the source pathname. The daemon process on the source system which transfers the file or subtree must also have the same type of access as described above for the source system's user. Additionally, the daemon must also have at least "s" access to the directory above the containing directory of the specified object in order to verify that the user and daemon have the proper access. The identity of the daemon can be determined using the print_imft_sites command. The user on the target system must have explicit "sma" access to the directory into which the file or subtree is to be placed. The source system user and the target system user are the same unless the -foreign_user control argument is specified. The user also needs "sma" access to the parent directory of the source and "rw" access to the source object if the -delete control argument is specified. The daemon process on the target system which receives the file or subtree must also have explicit "sma" access to the directory into which the file or subtree will be placed. If the source object is to be deleted, the daemon process must also have "sma" to the containing directory of the object and "rw" to the source object. In addition, this daemon must have at least "s" access to the directory containing that directory in order to validate that the target user has the proper access. If the -extend or -update options are used, the target file must exist and the user (for pull transfers) or foreign_user (for push transfers) must have an explicit "rw" ACL entry on the target file. The daemon on the target system must also have an explicit "rw" ACL entry on the target file. Access control segment: The ability of a user on the local system (LPerson.LProj) to transfer files to or from the foreign system is controlled by the access granted to the local user by the user on the foreign system (FPerson.FProj) to the segment: >udd>FProj>FPerson>LSite.imft.acs on the foreign system where LSite is the name of the local system. In order to request that files be transferred from the foreign system, LPerson.LProj.* must have explicit read access to the above-named segment. In order to transfer files to the foreign system, LPerson.LProj.* must have explicit write access to the segment. (Note: when setting write access on an ACS, it is advisable to set its maximum length to 0, to prevent it from acquiring contents.) In the case of remote requests (i.e., use of the -source control argument), the foreign and local users must have all the same access as if the request had been issued at the source system, in addition to read access to the ACS as indicated above. An example of access requirements (local to remote file tranfer): This type of transfer request is also known as a push request. Assume that the user Smith.Multics on MIT wishes to send the file >udd>m>Smith>test>new.pl1 to the directory >udd>Guest>SmithP>imft>mit on System-M where his user ID is SmithP.Guest. Further, assume that the daemon on both systems is IMFT.Daemon, and that the names of the source and target systems (given by print_imft_sites command) are MIT and System-M respectively. On MIT (the source system), Smith.Multics must issue the following set_acl commands to insure that he and the daemon have proper access; set_acl >udd>m>Smith>test>new.pl1 r Smith.Multics r IMFT.Daemon set_acl >udd>m>Smith>test s IMFT.Daemon Note that the daemon must have at least "s" access to >udd>m>Smith in order to check that the above explicit ACLs are present. Only in this case will any ACL term which grants appropriate access to the daemon for these checks is sufficient, ie, IMFT.*.* or *.Daemon.* or *.*.* will suffice. On System-M, SmithP.Guest issues the following set_acl commands to insure proper access to receive the file; set_acl >udd>Guest>SmithP>imft>mit sma SmithP.Guest sma IMFT.Daemon set_acl >udd>Guest>SmithP>imft s IMFT.* set_acl >udd>Guest>SmithP>MIT.imft.acs w Smith.Multics Once proper access is established, Smith.Multics issues the command line; eir >udd>m>Smith>test>new.pl1 -tpn >udd>Guest>SmithP>imft>mit>=== -fu SmithP.Guest -ds System-M An example of access requirements (remote to local file tranfer): For a related example, let's assume that the same user wants to transfer the same file as a remote request (i.e., he wants to issue the request while logged in at System-M as SmithP.Guest.) To do this, he needs exactly the same access as described above, with one exception. Instead of giving himself "w" access to the ACS segment, he must establish "r" access with the following command line at MIT: set_acl >udd>Multics>Smith>System-M.imft.acs r SmithP.Guest SmithP.Guest may now request the transfer by issuing the command line on System-M; eir >udd>Multics>Smith>test>new.pl1 -tpn >udd>Guest>SmithP>imft>mit>=== -fu Smith.Multics -source MIT Notes on AIM: Files and subtrees may be transferred only if their access class is less than or equal to the process authorization of the user who submitted the request and the common access class ceiling. Type: help common_access_ceiling.gi for a definition of the common access class ceiling. The sites may chose to lower the common access class ceiling; check with your system administrators to find out the actual common access class ceiling. Files and subtrees are created on the target system with the same access class as they had on the source system. When transferring a subtree, the daemon will not transfer any directory in the subtree if its access class is greater than that of the directory where it will be placed on the target system. Therefore, it is necessary to issue separate requests for each such upgraded directory specifying a target pathname whose containing directory has the same access class as the directory being transferred. For example, if the access class of the directory on the source system is "classified, Division" and the command line: eir my_directory -tpn >udd>m>gmp>receiver>=== is issued, the access class of the directory >udd>m>gmp>receiver on the target system must also be "classified, Division". Notes: If conflicting control arguments (e.g., -notify and -no_notify, or -destination and -source, or -extend, -replace and -update, or -replace_directories and -merge_directories) are given on the command line, the rightmost control argument takes effect. If -extend or -update control arguments are not used, and there is an entry on the target system with the same name as one of the names on the file being transferred, that name will be removed from the target entry; if the target entry has only one name, it will be deleted. No distinction is made between files specified in a transfer_spec and files contained in a subtree with respect to the handling of duplicate names on the target system. Examples of usage: eir **.pl1 -tpn ===.new -ds MIT transfers all files and subtrees in the working directory whose name ends with the pl1 suffix. If the local working directory is >udd>m>gmp>w, a file named "foo.pl1" will appear on the remote system as >udd>m>gmp>x>foo.pl1.new eir my_subtree -ds System-M -mdr transfers the subtree named "my_subtree" in the working directory to the same point in the hierarchy on the remote system. Assume (1) that there already is a foreign directory named my_subtree, (2) that the local my_subtree contains two files named file1 and file2 and a directory named subdir1, and (3) that the foreign my_subtree also contains two files named file1 and file3. After the transfer is completed, the foreign my_subtree will contain three files -- file1 and file2 from the local system and file3 from the foreign system -- and one directory -- subdir1 from the local system along with the contents of the local subdir1. eir >udd>sm>Kelley.profile -tpn >udd>m>PKelley.= -source MIT -fu Kelley.SysMaint transfers the segment >udd>sm>Kelley.profile from MIT on behalf of the MIT user Kelley.SysMaint, and places it in >udd>m>PKelley.profile on the local system. ----------------------------------------------------------- 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