id summary reporter owner description type status priority milestone component version resolution keywords cc 267 mbuild poorly diagnoses .mb seg giving wrong library.directory for a segment Gary Dixon Gary Dixon "The recent update to mbuild introduced a problem in diagnosing a build script that references the wrong library.directory name for a segment being installed. In the simplest example, a build directory contains only a build script plus an info segment being installed. {{{ ls Segments = 2, Lengths = 12. r w 1 mb_01.mb rew 11 history_comment.info hcom.info hcom.add.info hcom.add_field.info hcom.af.info hcom.check.info hcom.ck.info hcom.compare.info hcom.cmp.info hcom.display.info hcom.ds.info hcom.exists.info hcom.format.info hcom.fmt.info hcom.get.info hcom.install.info hcom.replace_field.info hcom.rpf.info hcom_validation_rtn_.info }}} The build script contains only a REPLACE operation for the file, but specifies the wrong library in the lib.dir specification: priv.info (or >doc>priv directory). {{{ Installation_directory: >udd>m>gd>w>mb_01; Build_script: mb_01.mb; Info: history_comment.info IN: priv.info REPLACE; add_name: hcom.info hcom.add.info hcom.add_field.info hcom.af.info hcom.check.info hcom.ck.info hcom.compare.info hcom.cmp.info hcom.display.info hcom.ds.info hcom.exists.info hcom.format.info hcom.fmt.info hcom.get.info hcom.install.info hcom.replace_field.info hcom.rpf.info hcom_validation_rtn_.info; }}} This file is actually located in the sss.info directory (>doc>info). Invoking mbuild in the directory automatically runs scan and read requests. scan lists segments in the directory, and adds a Seg structure for each segment to both scan_Tb and Seg_Tb threads in mbuild's data base. The scan_Tb thread holds items found by scan and/or read requests. The Seg_Tb thread holds all Seg structures created in mbuild's data list (no matter which request creates that Seg structure). As a Seg structure is created, code attempts to find a corresponding segment in the Multics libraries. If found, that lib.dir is assigned as the new Seg.library value. No Seg.operation value is specified. This state is shown in the output below. {{{ mbuild: p Segments found by scan request: Build_script: mb_01.mb; Seg(Info): history_comment.info IN: sss.info; add_name: hcom.info hcom.add.info hcom.add_field.info hcom.af.info hcom.check.info hcom.ck.info hcom.compare.info hcom.cmp.info hcom.display.info hcom.ds.info hcom.exists.info hcom.format.info hcom.fmt.info hcom.get.info hcom.install.info hcom.replace_field.info hcom.rpf.info hcom_validation_rtn_.info; }}} A subsequent read request examines lines in the .mb build script, tries to match them with items in the scan_Tb thread. Because the line in the .mb file refers to the priv.info directory: {{{ Info: history_comment.info IN: priv.info REPLACE; }}} it does NOT match the Seg(Info).history_comment.info item in the scan_Tb list, which has Seg.library=""sss.info"". So a second Seg structure is created. This replaces the first Seg structure on the scan_Tb list, though that Seg remains on the Seg_Tb list. {{{ mbuild: read mbuild: p Segments found by read request: Build_script: mb_01.mb; Seg(Info): history_comment.info IN: priv.info ADD; }}} Because two different library directories were involved, there are two Seg structures dealing with history_comment.info in mbuild's database. {{{ mbuild: p -ls all -a scan_Tb: Seg(Build_script): mb_01.mb; Seg(Info): history_comment.info IN: priv.info ADD; Seg_Tb: Seg(Info): history_comment.info IN: sss.info; add_name: hcom.info hcom.add.info hcom.add_field.info hcom.af.info hcom.check.info hcom.ck.info hcom.compare.info hcom.cmp.info hcom.display.info hcom.ds.info hcom.exists.info hcom.format.info hcom.fmt.info hcom.get.info hcom.install.info hcom.replace_field.info hcom.rpf.info hcom_validation_rtn_.info; Seg(Build_script): mb_01.mb; Seg(Info): history_comment.info IN: priv.info ADD; }}} The Seg on the scan_Tb list has the correct Seg.name - ""history_comment.info"", but no add_name list, the wrong Seg.operation value, and the Seg.library=""priv.info"" given incorrectly in the build script. And the user has received NO WARNINGS or ERRORS about this discrepancy! Running an mbuild analyze request continues with the incorrect information, and still reports no errors or warnings to the user. {{{ mbuild: analyze ---------- clean -all ---------- progress COMPLETED REQUESTS for Builds --------- ---------------------------- set -desc or read -desc yes scan and/or read yes analyze yes compile yes archive_prep install_ec mbuild: p Build_script: mb_01.mb ADD; Info: history_comment.info IN: priv.info ADD; }}} If the user fails to notice that his intended REPLACE of an info segment was now turned into an ADD operation, then continuing the installation would install the new file into >doc>privhistory_comment.info, while leaving the >doc>info>history_comment.info installed as well. This duplicate file would clearly be wrong, but it is not immediately obvious to the user. " defect closed major MR12.7 Tools MR12.7 fixed