compare_entry_names tool has several problems.

[Gary Dixon]

PROBLEM 1: The compare_entry_names tool is documented to compare the names on two file system entries.

help compare_entry_names -all

>doc>info>compare_entry_names.info   (14 lines in info)

1986-01-28  compare_entry_names, cen

Syntax as a command:  cen path1 path2

Function: compares the names on two entries in the storage system and
prints information about the differences.

Arguments:
path1
   is the pathname of the first entry.  You can't use the star
   convention.
path2
   is the pathname of the second entry.  You can use the equal
   convention.

However, because it chases links when locating the two "entries", it fails to compare names on a branch with names on a link to that branch that is located in a different directory. Instead, it compares unique IDs of the two entries and complains they are the same segment.

The function it is actually performing should be called compare_branch_names.

To correct this problem:

A) calls to hcs_$status_long should pass a NO_CHASE argument value; and
B) the code should check if either entry is a Link before comparing unique IDs of the two branches. If either is a Link, then it must skip unique ID comparison because Link entries do not have a unique ID.

PROBLEM 2: Because of a well-known flaw in the design of the hcs_$status_ and hcs_$status_long interfaces, the names on the target entry may be allocated in an extension component of an extensible area, and therefore may not be addressable by the calling program.

From status_structures.incl.pl1, the declaration for the name array returned by these two subroutines is declared as shown below. In declaring status_entry_names, the array is located by combining the baseptr of the FIRST component segment of the extensible area with a relative offset of the allocated array within SOME component segment of the extensible area. But the caller cannot tell which component holds the name array. That is the flaw.

dcl 1 status_branch aligned based (status_ptr),
    2 short aligned,
      3 type fixed bin (2) unaligned unsigned,              /* seg, dir, or link */
      3 nnames fixed bin (16) unaligned unsigned,           /* number of names */
      3 names_relp bit (18) unaligned,                      /* see entry_names dcl */
         ...

dcl  status_entry_names (status_branch.nnames) character (32) aligned
          based (pointer (status_area_ptr, status_branch.names_relp));

compare_entry_names uses the area provided by get_system_free_area_ which is an extensible area. Therefore, it is susceptible to this problem.

One possible solution is to use a non-extensible automatic area sufficiently large to hold the name array allocations. For example, an area of 17000 words is large enough to hold two 1000-entry name arrays, and would occupy only 17 pages of stack storage.

PROBLEM 3: compare_entry_names tries to rejoin the directory and entryname portions of a pathname back together by just separating the two names with a greater-than (>) character. For example:

      call ioa_ ("^/Names unique to ^a>^a", dname1, ename1);

This method fails for entries in the root (>) directory. It should be joining the two portions using the pathname_ subroutine.