(v13) SearchOrder and ObeySearchDevice

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP.

The behavior described in (v13) Searching for files can be modified with SearchOrder, an integer valued device parameter. In principle, positive values specify the order in which devices are searched for a file; however, this behavior is not implemented. A device with a negative SearchOrder is excluded from the search altogether, and this is implemented.

There are two cases where this could make a difference: when using the filenameforall operator, and when giving an (unqualified) filename as argument to file, status, deletefile,  or renamefile. When does it in fact make a difference? This is controlled by the system parameter ObeySearchDevice, which is an array of two Booleans.

If the first Boolean is true , then filenameforall, when executed with a template that does not include a device name (with or without a pattern), searches only devices with a non-negative SearchOrder. That is, if any device name or device pattern is supplied, all devices matching that pattern will be searched including those with a negative SearchOrder.

If it is false, all relative devices are searched unconditionally, as defined in [RB2].

Similarly, if the second Boolean is true, the file, status, deletefile, and renamefile operators search only devices with a non-negative SearchOrder; if it is false, they search all relative devices (where no explicit device name is given) as in [RB2].

From HHR v11.0r1, the first and second Boolean for HHR are (by default) both true. The default for HMR has been [true true] for some time.

This causes some files operators, notably file, which is usually used to open files for reading and writing (not to search devices that forbid searching). Therefore, some jobs that ran in previous releases, may now fail with undefinedfile. In these cases, the file argument is missing the %device% part, and the file is stored on a device that is not marked as searchable. Network disks are mounted like this by default. Avoid this by providing the full filename with device (disk) included, but note that enabling searching on network drives can lead to reduced performance.

Thus where:

(/tmp/foo) (r) file

no longer finds the file, we recommend that you replace it with the full filename containing the device (typically %/% on Unix, and %C% on Windows). For example:

(%/%tmp/foo) (r) file

and

(%C%tmp/foo) (r) file

Alternatively, you can change the search settings, as stated above.

Many devices in GUI versions of the RIP have SearchOrder set to –1. This is for three pragmatic reasons:

• A device can represent a portion of the underlying operating system’s file system (or some other resource). Two or more devices can be mounted that actually represent the same, or overlapping, parts of the file system. If searching were not suppressed, filenameforall might report the same file twice, and searching might locate the file on a device that was not intended. An example of this is the GUI version’s devices %disk0% and %os%. These both refer to the SW directory containing the Harlequin RIP’s database. This is because [RB2] defines the base filing system to have the name %os%; however, this does not correspond to actual use where font downloaders and other utilities generally assume that the names of disks attached to a printer are called disk n. To be correct for both, both devices are mounted, but only %disk0% is searchable.
• When an AppleTalk job runs, the sending machine first executes a small job that makes queries about the PostScript-language environment: which fonts are installed, for example. Unfortunately, it only allows a limited amount of space for the reply, so it is important to suppress unnecessary information.
• If all devices were searchable, the AppleTalk query would take an unacceptably long time. To determine which fonts are present on disk (having first determined that there is at least one disk), the application or printer driver runs something like this:
  
  (fonts/*) {...} 100 string filenameforall

In principle, this searches all mounted file systems. On networked disks, this could end up searching the whole network at the start of each job. (A newer printer driver would use resourceforall on the Font resource category, which can be much more efficient.)

From HHR v11.0r4, set SearchOrder for %os% device to -1 in SW/Sys/ExtraDevices  (per HMR).