• Contents
  • 1 About the chapters of this manual
  • 2 An introduction to HELIOS PCShare
  • 3 HELIOS Admin
  • 4 PCShare SMB file and print services
  • 5 Preferences
  • A Connecting Windows clients to the PCShare server
  • B Technical notes
  • C Glossary
• <
• 4 PCShare SMB file and print services
  • 4.1 Server file system information
  • 4.2 PCShare WINS and browsing
  •  4.2.1 Browsing
  •  4.2.2 Name resolution with WINS
  •  4.2.3 Name resolution with WINS proxy
  •  4.2.4 Querying PCShare for WINS & Configuration information
  • 4.3 HELIOS PCShare Client Tools
  •  4.3.1 PCShare UNIX file permissions
  •  4.3.2 HELIOS Meta information
  •  4.3.3 HELIOS PCShare Search
  •  4.3.4 HELIOS CLI tool “helsearch.exe”
  • 4.4 Printing to Windows workstation printers via SMB
  • 4.5 Print server utility programs
• >

 

4 PCShare SMB file and print services

PCShare implements a Windows 2003 SMB/CIFS compatible file and print server. The main goal of PCShare is to offer the highest compatibility for file and print services, and to support all major Windows clients as well as DOS clients with its native protocol.

The SMB/CIFS protocol is also used for named pipes where Microsoft provides additional protocols for their Exchange Server, Remote Procedure Calls, Remote Registry, etc. PCShare implements file and print services only. If PCShare should fail in a special workflow or application, please help to get the problem reproducible by documenting a simplified test case and report it to your HELIOS partner. Due to an incomplete documentation for the SMB/ CIFS protocol by Microsoft and continuously changing Windows versions via updates and upgrades, PCShare is continuously enhanced by updates and upgrades. Please ensure to verify problems against the latest version and update level.

The PCShare server uses the HELIOS authentication server which allows local host users, NIS, LDAP and AD/PDC users. PCShare supports all required SMB/CIFS user authentication methods, including Lan Manager, NTLMv1 and NTLMv2.

The PCShare server supports the default HELIOS TCP/IP access lists for its services as well as a custom access list per volume to hide/show volumes for remote users.

PCShare clients run with the effective authenticated user and group permissions, which means UNIX file access permissions and user quota limits are enforced by the operating system. UNIX file and directory permissions are fully supported and can be managed in the PCShare tab of the Windows Explorer “Documents Properties” dialog, using server host tools, from Macs connected via EtherShare or from WebShare web clients. Each PCShare TCP/IP client runs in its own process which provides higher process security in case of a protocol failure.

For new files and folders, PCShare will automatically inherit file permissions from the parent directory. For new directories, the “g+s” bit is set (if permitted). This allows quota group enforcements.

PCShare requires HELIOS UTF-8 volumes which are compatible with the HELIOS EtherShare AFP server for Mac clients and HELIOS WebShare for remote web clients. PCShare supports the Unicode protocol for Windows clients allowing them to use the same file names compatible to Windows NTFS volumes. File names can have up to 255 characters and short names are supported for clients requiring it.

PCShare handles Windows NTFS file streams and related commands (create/rename/move/remove). This enables enhanced compatibility with Windows servers and NTFS as well as better cross-platform support. Windows file streams are preserved even after a Windows file is modified by an EtherShare Mac or WebShare web client. The file streams are stored in the “.rsrc” directory.

PCShare supports the Windows file and directory attributes “System”, “Hidden”, “Archive”, “Read-only” and “Creation date”. These attributes are stored in the HELIOS resource file in the “.rsrc” directory. The attributes are stored in an EtherShare and WebShare compatible format, i.e. in a hidden file which is hidden as well for Mac or web clients.

HELIOS Base includes batch tools to allow host batch compatible file management, e.g. “cp”, “mv”, “mkdir”, “rm” , “chmod”, “touch”. The “dt” tools will handle additional file information like file streams, Windows attributes, Mac resource information, and update the volume desktop database.

PCShare supports the HELIOS desktop database. Each volume contains a desktop database file which keeps an index of all files with associated unique file IDs.

PCShare supports file events which are used by ImageServer hot folder scripts and automatic OPI layout file generation. The events are generated based on file suffixes and Mac file types. The ImageServer TCP/IP port 2002 allows clients to be notified about file changes.

User quota limits are enforced. The PCShare server reports the user quota limited available disk space to its clients.

It is recommended to use a host based backup solution to backup PCShare volumes. A host backup solution will backup all information including file mode, owner and group. Some host backup solutions will automatically handle the resource information and additional file streams when selecting individual files. It is always safe to select complete folders for backup instead of single files, this means all related streams and attributes will automatically be archived because they are stored in the “.rsrc” subdirectory of each directory. A remote backup from Windows is possible but the UNIX owner, group and mode information of files and directories is not supported by the SMB/CIFS protocol and will therefore lead to default permissions in case of a restore.

PCShare will publish its printers via the SMB/CIFS printing protocol. Authenticated Windows clients will automatically see all published printers in the Windows Printers and Faxes list. After connecting to the shared printer queue the Windows print manager will show the print jobs. Removing jobs is only allowed by the owner or by admin users. It is recommended to use HELIOS Admin for more advanced queue management. The PCShare specified printer driver name allows Windows clients to automatically install the required printer driver if the driver name matches an installable driver within the Windows driver path. HELIOS Base provides the HELIOS printing system used by PCShare and all other HELIOS products. “lpr/​lpc/​lprm/​lpq” compatible tools allow inspecting and modifying print jobs/queues.

The WTS provides multiple sessions for different users. It connects only once to an SMB/CIFS server and multiplexes the different user sessions over a single TCP/IP connection. The same technique is used for Windows XP user switching where different user sessions can connect to the same SMB/CIFS share. PCShare has been tested with WTS and Windows XP sessions and supports the user session switching feature over a single connection. In heavy duty client environments, separate Windows clients (no WTS) have a significant performance benefit over WTS sessions where the SMB/CIFS access is being serialized by a single TCP/IP connection.

Using “oplocks”, Windows may cache the entire file until a second client accesses the same file. PCShare supports Windows oplocks, EtherShare and ImageServer will handle oplock cached files. Ensure that oplock files get flushed before accessing their data. Accessing files manually via host tools may not provide the correct data for files with oplocks. Use the “locktable” command (HELIOS Base) to list all open files and oplocks attributes.

Full Windows compatible file and record locking is provided by PCShare and shared with EtherShare and other HELIOS programs to permit true cross-platform file and record locking for Windows, Mac and mixed client environments. To provide fast and fully compatible file and record locking, HELIOS stores all locks in a shared memory which allows accessing locks without additional system calls. Windows and Mac require that every read or write of bytes does not interfere with existing locks. Local server file access, NFS or shared Sun storage locks are neither compatible with Windows file and record locking nor with oplocks. Therefore the same data can only be published by one active PCShare server.

The following Windows network clients are supported by PCShare:

• Windows NT 4, 2000, XP, 2003, 2008, Vista, Windows 7

• Windows 95, 98, ME, 3.1, 3.11, DOS

4.1 Server file system information

The following table compares the behavior of the different operating systems regarding the case sensitivity.

As Table 4.1 shows, there is no case preserving under DOS, i.e. file names entered in lowercase will appear UPPERCASE in the directory listing. In contrast to UNIX, the Windows (as well as Mac) operating system is not case-sensitive when it looks for files or creates or opens them – if your application looks for “Dave”, it will also find “dave”, and you cannot create a file “Dave” and a file “dave” in the same folder in a local volume. Due to its UNIX heritage, this holds not true for HELIOS volumes.
This distinction is normally not a problem – if an application has created e.g. the file “Editor Prefs” and needs to open it again, it usually tries to open it using the same name and not “EDITOR PREFS”. If an application cannot find a file which it has created, and the file is visible under UNIX and in the Finder, it is likely that case-sensitivity is to blame. If you are able to determine the name of the file which the application is trying to open, you can often provide a workaround by using a Mac/​Windows link (alias) or by renaming the file.

4.2 PCShare WINS and browsing

4.2.1 Browsing

Name resolution through WINS (Windows Internet Name Service) or broadcasts deliver the matching IP address to a given NetBIOS name, like a telephone directory inquiry returns the telephone number to a given name.

To find out which IP address represents which NetBIOS name the following procedure is applied:

Each host sends in regular intervals so called “Host Announcements” all over the network. These are received by all computers on the subnet, but ignored by all except for the LMB (Local Master Browser). From the received “Host Announcements” the LMB generates the browse list, which contains all the names known to the LMB. The browse list becomes visible e.g. in the Windows My Network Places list.

One or several BB (Backup Browser) are subordinate to the LMB for load balancing purposes. Each BB requests the browse list from its LMB in regular intervals.

Each client which would like to receive the browse list, e.g. because a user opens the Windows My Network Places list, requests it arbitrarily (load balancing) from any LMB or BB.

On each subnet of a domain there is an LMB and a certain number of BB and clients. Domain in this context refers to the Windows NT Domain, not to confuse with an Internet Domain.

The development of the browsing hierarchy is a dynamic process and cannot be configured. Each host which would like to become LMB, and each host which would like to obtain a browse list but – for any reasons – does not obtain one, can enforce an election. However, unlike a political “election” here every node votes for itself and does not give its vote to another. An election consists of several heats. Each host votes for itself until it recognizes that another host has cast a more important vote.

The importance of a vote depends, among other things, on the operating system version and the uptime. A host running Windows NT Server “wins” before Windows NT Workstation, and NT Workstation wins before Windows 98, etc. In case of a “tie” the larger uptime and further criteria are decisive.

After a maximum of 4 heats the “winner” of the election is found and appoints itself LMB, appoints further hosts BB, or divests existing BBs of their powers with the target of an optimal load balancing.

A browse list is complete several minutes after the election. Therefore, frequent elections have a detrimental effect and therefore should be avoided.

The LMB administers the browse list of its subnets. In order to make the hosts of other subnets visible, all other LMB browse lists must come to each LMB’s knowledge. For that purpose each LMB connects with the DMB (Domain Master Browser) and synchronizes its browse list in regular intervals with the DMB. Thus, the local browse lists are assembled to a global browse list which covers the entire domain. This process can take up to 1 hour.

The DMB is the only arrangement within the browser hierarchy which must be configured. LMBs result from elections on a subnet by broadcasts. BBs are appointed by the respective LMB. The DMB must always also be LMB on its subnets. If the DMB loses the election another host becomes LMB. This usually leads to malfunctions.

In each domain there is a PDC (Primary Domain Controller) which, among other things, administers passwords. A PDC on the network can be found by use of the Primary Domain Controller Location Protocol, a sequence of special browsing packets and name resolution.

Microsoft determined that PDC and DMB have to be the same host. Because an LMB cannot find the DMB on the network it looks for the PDC and so relies on having found the DMB. See also Browsing in 4.2.3 “Name resolution with WINS proxy”.

Thus, a Windows NT Server DMB is always also PDC. PDC functionality is not yet implemented in PCShare – the DMB functionality however is. If PCShare is to function as DMB, it must register itself with the WINS as PDC, pretending PDC functionality, in order to be considered DMB from other LMBs.

Important:

If there is another PDC on the network, the PCShare server should under no circumstances be configured as DMB or PDC!

Each WINS client must know the IP address of the WINS, e.g. by static configuration or DHCP.

4.2.2 Name resolution with WINS

A NetBIOS name can be a group name, e.g. a Workgroup or a domain or a unique name, e.g. a computer, a service or a user. A NetBIOS name may consist of uppercase characters as well as some special characters and is restricted to max. 15 characters. If it is shorter than 15 characters it is appropriately filled with blanks. The 16th byte is a type byte, from which one can detect whether it concerns e.g. the name of a computer, of a user or of a service. Thus, each NetBIOS name is exactly 16 bytes long.

To make a computer, service, etc. on the network recognizable, it must first register itself. If another computer wants to access this name, it must do name resolution. For this to work, the IP address of the WINS must be known. Under PCShare the WINS server address can automatically be delivered via DHCP, when configured with HELIOS Admin.

A computer registers itself via WINS by sending it a Name Registration Request (unicast UDP). This datagram contains among other things the NetBIOS name and an IP address. The WINS answers with a positive Name Registration Response. This process is repeated in regular intervals (Name Refresh). If Name Refresh is not executed in the determined time interval, the WINS considers this client to have crashed or switched off, and removes its entry from the data base. Similarly a client which is switched off should log out with a Name Release Request from its WINS so that its name is immediately removed from the WINS data base and not only after a time-out. This however does not happen very often.

The WINS will reject a registration (negative Name Registration Response), e.g. if a client wants to register a name which another client has already registered successfully before. This leads then to an (possibly quite strange) error message at the unsuccessful PC.

A client, which needs to get a name resolved, sends a Name Query Request (unicast UDP) to the WINS. The WINS answers with a positive Name Query Response, which contains the IP address of the looked-up NetBIOS name or with a negative response, i.e. the looked-up name is not known to the WINS (anymore).

If name resolution with WINS fails the client still tries it with some Name Query Requests which are sent as broadcasts. If the looked-up NetBIOS name is located on the same subnet its carrier will answer with a unicast Name Query Response.

If this still fails DNS (Domain Name System) can be used.

In a larger network several WINS may share the tasks, e.g. for reasons of reliability or for load balancing purposes. These WINSs do replicate in regular intervals their data bases among themselves, in order to always share the same level of knowledge.

Note:

A replication from WINS is not implemented in PCShare at present, because Microsoft keeps the required “WINS Replication Protocol” secret. PCShare can be employed as exclusive WINS only.

4.2.3 Name resolution with WINS proxy

If the WINS is not known to PCs which are located on a subnet they can only use broadcasts for name resolution. In this case a WINS Proxy can be used as a link.

The IP address of the WINS must be known to the WINS Proxy. It listens on its subnet for broadcasts and forwards these to the WINS. It incorporates a local cache in order to hold network traffic within limits. Thus, the nodes on the broadcast subnet can also resolve names of computers or services which are on other subnets. However, this does not work the other way round.

The WINS Proxy should only be used for a transition period, until all nodes on the subnet are correctly configured and communicate directly with the WINS.

The communication with the WINS Proxy puts unnecessary workload on the network and can also cause additional problems. If a node gets more than one response after a broadcast it regards this as an error, even if the responses are correct and consistent, and rejects the received responses.

Nodes which do not communicate with the WINS broadcast their existence in regular intervals on their subnet. The WINS Proxy can then forward these broadcasts to the WINS. However, this does not lead to a registration of the broadcast node with the WINS, it is merely checked whether a broadcast node carries a name which a WINS client had already registered. If necessary, the WINS Proxy refuses the broadcast node registration.

HELIOS Admin allows making adjustments which influence he behavior of PCShare. Here, we discuss issues which affect name resolution and browsing.

For safety reasons it can be necessary to forbid computers with certain IP addresses to access the PCShare server. However, this option should only be used with caution because the structure of the browser hierarchy is a dynamic process, and therefore it is often not predictable which host will take which position in this hierarchy.

If any host requests a browse list but is prevented by the IP access list from doing so, this may lead to a new election. For this, it is irrelevant whether a user opened the Network Neighborhood list, it came by periodic testing of the browse list or the rejected host is located on the same or another subnet.

Note:

An inappropriately selected entry in the IP access list leads constantly to new elections. In this case you will be unable to get a stable and reliable browser hierarchy.

PCShare needs a NetBIOS host name as well as a NetBIOS domain name. If not configured in a different way, the host name is the PCShare server name, and the workgroup name is “WORKGROUP”:

PCShare will force – shortly after booting up – an election and try to become LMB. This behavior can also be turned off:

Microsoft did not define a mechanism which allows to find the DMB on the network. Instead, there is a mechanism (Primary Domain Controller Location Protocol) to find the PDC on the network. Hence PCs rely on the fact that they will thereby also find the DMB. On that score PCShare must pretend PDC behavior (i.e. respond to this PDC Location Protocol).

But this is just a fake behavior since full PDC functionality is not implemented in PCShare:

Of course, PCShare – if it is not the WINS itself – must know where to register itself and which arrangement is responsible for name resolution, e.g. 172.16.0.1.

PCShare itself can function as WINS or as WINS Proxy. In case of doubt, WINS Proxy should be switched off; WINS should only be switched on if PCShare is the only WINS on the network.

The Scope Identifier is a means to divide the flat NetBIOS name space into sections, when NetBIOS over TCP/IP is used. An hierarchy as in the DNS name space is however not realized. It defines a group of computers that recognize a registered NetBIOS name. Computers with the same Scope ID will be able to recognize each other’s NetBIOS traffic or messages.

4.2.4 Querying PCShare for WINS & Configuration information

With socket <ipaddress> 2003 or socket <hostname> 2003 a connection to the master PCShare process can be established and “Name Binding Service” configuration & status can be queried. The following short abstract shows how certain information can be listed.

Note:

In a complex network you may have to wait several minutes after starting PCShare before a stable browsing hierarchy has been reached.

The master PCShare server will respond with a status line which lists the PCShare version incl. update level, UNIX host name, PCShare server name and UNIX operating system as well as date and uptime of the PCShare master process.

Issue the command socket localhost 2003, type help for the command overview and quit to leave.

Note:

By default, the PCShare service port can only be reached from localhost. See RemoteAccess in 5.1 “PCShare preferences”.

PCShare 4.5.0 NBS (P610,p610,AIX), Wed Dec 09 15:02:21 2009, up since
Fri Dec 04 08:37:30 2009

Use “help” to list available commands:

quit

Terminate session.

status

Shows the master process status.

childs

Shows current child/client processes.

if

With if the configured TCP/IP interfaces are listed with TCP, broadcast and MAC address. If the interface is registered for PCShare the column “reg” lists “+”, otherwise “-”.

wins

With wins information about WINS will be listed as stored in “HELIOSDIR/​var/​run/​wins.db”, for example name and addresses, expiration date as well as type and state. In case the PCShare server is not WINS itself, this will return “No WINS entries”.

winsproxy

With winsproxy information about WINS proxy will be listed, see wins. In case the PCShare server itself is not WINS or there is no WINS proxy information, this will return “No Proxy WINS entries”.

winscl

With winscl current connection information about WINS will be listed, e.g. NetBIOS name, type and flags.

winstime

With winstime information about WINS will be listed ordered by time. See wins.

brconfig

With brconfig configuration information about the PCShare server is listed. Apart from host name, domain name and comment which are always listed, any changes to the default parameter settings are listed also. For example, if the PCShare server is not WINS.

browse

With browse all known browsing information is listed, e.g. domains, hosts, LMB & BB.

4.3 HELIOS PCShare Client Tools

The HELIOS PCShare Client Tools are:

• UNIX file permissions for Windows Explorer

• HELIOS Meta information

• HELIOS PCShare Search

• HELIOS CLI tool “helsearch.exe”

Each HELIOS PCShare Client Tools functionality is described in the following sections.

If the PCShare “Explorer UNIX permissions” shell extension was already installed, please uninstall the old version before installing the new tools.

Use the Windows “Add or Remove Programs” Control Panel to uninstall older versions of the “PCShare Client Tools”.

The PCShare Client Tools must be installed locally in order to provide the additional Windows Explorer UNIX permissions, HELIOS Meta information, and the PCShare Search function.

Map the network drive “HELIOS_APPS”, double-click the file “setup.exe” from “Windows > PCShare Tools > PCShare Client Tools” and follow the instructions in the installation dialog.

Note:

The following functionality is only supported up to Windows XP/​Server 2003:

Windows Explorer can display information on UNIX file permissions for owner, group and others as well as meta data like label color and comments provided by the PCShare Client Tools in own columns.

To activate these columns, do a right-click on the column header in the Windows Explorer file browser and activate in the pop-up menu those items that should be displayed (scroll down in dialog; all options start with “HELIOS)”.

4.3.1 PCShare UNIX file permissions

PCShare allows the user to review and change UNIX file and folder permissions. Items that can be modified are UNIX file permissions, user, and group.

The benefit is that you have transparent permissions between Windows, UNIX, Mac, and web clients. Permissions can easily be changed in the PCShare tab of the Windows Properties dialog (Fig. 4.1).

The volume for which you wish to review or change UNIX file and folder permissions must be mapped as a Windows network drive, otherwise the PCShare tab will not be available in the Properties window.

In My Network Places open Tools > Map Network Drive..., and select from the Drive pop-up menu a letter for the network drive, e.g. “Z:”. From the Folder pop-up menu select the volume path which you want to map to the network drive. You may also browse for a volume by means of the Browse... button.

In the “PCShare UNIX file permissions” section you can now specify access rights according to your needs.

If you activate the checkbox Change permission on all files in every subdirectory, which applies your permission changes to all files below the path, the option Change the ownership/group for all files becomes available. This option has almost the same effect as the one described above, with the difference that it applies all owner/group related changes to files below the path. To set advanced file and directory permissions, click the Advanced... button. A new window opens (Fig. 4.2), allowing you to set additional flags, e.g. the execute flag for user, group, and other.

To have the Advanced... button available without being logged-in as “root” on the network drive, you can temporarily log in as “root” by clicking the button Login as another user. A dialog opens that allows you to log in as a different user.

4.3.2 HELIOS Meta information

The HELIOS Meta information tab (Fig. 4.3) is a PCShare feature, which has been installed with the shell extension (see Installing the PCShare Client Tools).

This tab in the file/folder “Properties” allows adding a file comment and mapping a color label to the file.

You can define seven color labels in HELIOS Admin that will be available on Windows, Mac OS 8/9 or WebShare clients. See the Base UB2 manual for details.

Click the Import Server Colors button to load the color label scheme from the server.

PCShare allows adding file comments to a file or folder. They are available on Windows, Mac OS 8/9 or WebShare clients. Mac OS X support is planned.
The comments are stored in file streams as SFM compatible AFP comments and work on any local NTFS disk and PCShare network drive. Comments are limited to 199 bytes. (Please note that comments are stored in UTF-8 encoding in which special characters and umlauts require more than one byte per character.)

Enter a file comment in the Comment field.

In the example above, the file “Cafeteria.tif” has been assigned the color label “Red” and a comment.

4.3.3 HELIOS PCShare Search

This feature allows you to search in a HELIOS volume that is mapped as a network drive for files and folders. The search is realized in the desktop database of the respective HELIOS volume. This results in a considerably faster search compared to the standard Explorer file search, especially in larger volumes. This is because there is no need to search the complete volume. The search can even be limited to the current folder by starting the search from within the respective folder.

In Windows Explorer highlight the HELIOS network drive, or a file/folder within this network drive, on that you want to perform the file search.

Then open HELIOS PCShare Search (Fig. 4.4) from the File menu or, via the right mouse button, from a folder context menu.

The Files on pop-up menu displays the selected target destination (mapped HELIOS network drive) for the file search (“Y” in the example above). To search in a different place, the respective HELIOS network drive letter must be selected from the pop-up menu. For this to work, the directory must be mapped as a network drive.

In the text field enter the search term and select from the pop-up menu whether the search term should be contained in the file name or exactly match the file name.

You may restrict the search results by use of the modification date (Modified pop-up menu) and by limiting the results to a certain number of hits (Max. Results pop-up menu).

Note:

The button opens a help page in the web browser, which lists common Spotlight search examples.

Click the Search button.

Note:

Though also non-HELIOS network drives are selectable from the pop-up menu, HELIOS PCShare Search will issue an error message if you try to do a file search on non-HELIOS network drives.

In the example above we searched for files named “Cafeteria-RG” on the network drive “Z”. The result (Fig. 4.5) displays 6 files whose names contain the search term “Cafeteria-RG”. If the search term was defined as Filename Exact Match instead of Filename Contains, there would not be any matches.

In addition, the search criteria Spotlight Search can be selected from the pop-up menu. Details are described in the chapter “Searching on Windows” in the HELIOS Index Server manual.

A double-click on an entry in the search results list will open the file in an appropriate program. The context menu (via the right mouse button) allows opening the enclosing folder of the selected file. The status line states the number of search results (compare Fig. 4.4 and Fig. 4.5).

Note:

The search is case-insensitive, i.e. if you search for “Cafeteria-rgb” the result would be the same.

To terminate the search and to close the window press the escape button.

4.3.4 HELIOS CLI tool “helsearch.exe”

“helsearch” is a command line search program which allows you to find files in a PCShare network drive by means of their whole file name or partial matches. “helsearch.exe” is the CLI version of the GUI-based PCShare search (see 4.3.3 “HELIOS PCShare Search”) and is suitable for scripting purposes.

Usage:

helsearch.exe [-A][-c][-e][-f][-r][-s][-t][-h]
              <Drive:[\path\scope]> <pattern> <searchterm>

-A

List available Spotlight search attributes for <Drive:>

-c

If output is written to a console send output to console in Unicode mode. Without this option and in all other cases output is written in UTF-8

-e

(File name search only): matches partial file names

-f

File name search instead of Spotlight search (conflicts with -s)

-r

Print file names in HELIOS convention (e.g. “/​C:/​Helios/​bin/​swho.exe” instead of “C:\​Helios\​bin\​swho.exe”)

-s

<pattern> uses advanced Spotlight syntax

-t

Print modification date (seconds since January 1, 1970) and file name

-h

Print this help

More details on the HELIOS Spotlight search, and search options, are covered in the HELIOS Index Server manual, in the chapters “Simple Spotlight syntax” and “Advanced Spotlight syntax”.

4.4 Printing to Windows workstation printers via SMB

“smbif” is the interface program for printers that are connected to the print server through SMB. It is used for all PostScript printers (including imagesetters). “smbif” forms the link between the HELIOS LPR and Windows printers.

Print jobs received by the print server from a workstation on the network are processed and queued before being sent to the SMB printer through the network again.

Due to print job spooling, it is more efficient to drive Windows printers through the print server, rather than accessing them directly from the workstations. We recommend that you select an appropriate name for the queue which shows which printer it drives and also indicates that it is a queue and not the printer itself. For example, add “spooler” to the printer’s name. See 3.5 “Windows printer output settings”.

4.5 Print server utility programs

The “pcfilter” program, which was designed to be used by the PCShare print spooler, can be used to carry out print job filtering and character set translation operations which are commonly required for different types of ASCII-printers.

Usage:

pcfilter <printer_name>

“pcfilter” is called by UNIX with command line options.

[-d]	Filter out “CTRL-D” in PS
[-f]	Add “form feed” to last page
[-c crmapping]	Map 'cr' to 'crlf', 'lf' or 'lfcr'
[-l lfmapping]	Map 'lf' to 'crlf', 'cr' or 'lfcr'
[-I initsequence]	Byte sequence at start of job
[-E exitsequence]	Byte sequence at end of job
[-i inputcharset]	Input character set …
[-o outputcharset]	… maps to output character set

For example, to automatically add a “form feed” character to the last page of each print job, the -f option must be specified:

$ pcfilter -f

“pcfilter” can also be called with the name of an exported printer. It references an option list for the particular printer in the “Preferences” file. In the following example a “form feed” flag for the printer “ljet” is set:

# prefvalue -k 'Printers/ljet/pcfilter/formfeed' -t bool TRUE

Appropriate entries in the “Preferences” file are made automatically when you export printers via HELIOS Admin. To choose print job filtering or character set translation use PCShare Admin. This is much easier than doing it manually (see 5.2 ““pcfilter” preferences”).

The “pcfilter” options in “Preferences” are:

formfeed

Add FF character to last page of job

ctrld

Filter CTRL-D characters from job and prefix each job with “%!PS”

cr (=crlf)

Convert CR characters to CRLF

cr (=none)

Strip CR characters

lf (=crlf)

Convert LF characters to CRLF

lf (=none)

Strip LF characters

init (=<string>

Specify initialization string

exit (=<string>

Specify exit string

input (=<name>)

File name of input character mapping table (optional)

output (=<name>)

File name of output character mapping table (optional)

postscript

Resolves PostScript jobs to a TCP, Remote LPR, Print To Disk or Windows Printer printer queue

If specified, the parameters input=name and output=name must always be specified as a pair.

init and exit string are both limited to 1000 bytes in length.

PCShare has the following character mapping tables in “HELIOSDIR/​var/​cmaps” for use by “pcfilter”:

Postscript, iso7, iso8, pc, mac, ebcdic, epson

The ISO7 table only maps characters from hex. 00-7f. All other tables map all characters from hex. 00-ff.

The Epson and EBCDIC tables are provided as examples only. The Epson table is compatible with the FX10-50 and FX80-50 printers and the EBCDIC table only maps the valid EBCDIC codes.

Note:

If your print job contains character codes which are not specified (i.e. missing) in the chosen input table, these codes are ignored and an error message is issued to the system message file. A maximum of 10 such messages are written per print job.
If your print job contains character codes which are not specified in the chosen output table, these codes are ignored and not passed to the printer.

The tables are specially compiled binary mapping files which can only be edited using PCShare Admin or the “prefvalue” command (see the description of “prefvalue” in the Base manual for related information).
You can also specify “pcfilter” for a local Windows printer which is configured to receive print jobs from a UNIX spool queue. Here is an example from the “Preferences” file:

[][Printers][epson-1][pcfilter][formfeed] 
flags=0 
type=Boolean 
value=TRUE 
[][Printers][epson-1][pcfilter][ctrld] 
flags=0 
type=Boolean 
value=FALSE 
[][Printers][epson-1][pcfilter][postscript] 
flags=0
type=Boolean 
value=FALSE 
[][Printers][epson-1][pcfilter][exit] 
flags=0 
type=String 
value=[4] 
\007 
[][Printers][epson-1][pcfilter][input] 
flags=0 
type=String 
value=[4] 
iso8 
[][Printers][epson-1][pcfilter][output] 
flags=0 
type=String 
value=[2] 
pc

“pcfilter” can also be used to correct several PC-specific problems which can occur when printing to a PostScript printer which is connected to the host via a network.

Particularly when printing PostScript from Microsoft Windows, a “CTRL-D” character is often included with the print job data to indicate end-of-job to the printer.

If you are using a PostScript printer with a network connection, it is necessary to filter out the “CTRL-D” since it will cause a printer error. This is because it is the responsibility of the print server and not of the application program to signal end-of-job in a way appropriate to the chosen hardware interface (RS-232, Ethernet, etc.).

Furthermore, some PostScript printers expect the character string “%!PS” at the very beginning of each PostScript print job. If this string is missing it is assumed that the file is plain text, which is then automatically converted to PostScript before printing, resulting in the printout of a PostScript program listing rather than the print job itself.

If you are using a PostScript printer connected to the host, you can filter out “CTRL-D” characters and add “%!PS” to the start of each print job, by specifying PCShare’s “pcfilter” utility in the UNIX print command.

An appropriate print command is created automatically when you configure printers with PCShare Admin and choose a PostScript character mapping table. See also the description of the magic preference in the HELIOS Base manual for related information.

Note:

When printing to an “lpr” printer queue, make sure that you switch off the Send CTRL+D Before Each Job and Send CTRL+D After Each Job checkboxes in the Windows printers preferences. Network printers do not understand “CTRL-D” characters.

Each PCShare SMB/CIFS queue contains the “pcfilter” program in its export specifications. This is automatically set by the HELIOS Admin SMB/CIFS printer publishing setup (Windows tab in the printer settings dialog).

---