Kap13.html

This chapter describes the function and configuration of the desktop server. The desktop server is responsible for storing icon and application data for the entire EtherShare server, and for managing file and directory IDs for network volumes. The desktop server is usually invisible to users and has no associated Macintosh application. The exception is the Rebuild Desktop option in HELIOS Admin.

The desktop server system consists of the program "desksrv". It is created in the "HELIOSDIR/sbin" directory during the installation. HELIOS Base is configured to start "desksrv" automatically when UNIX is booted.

"desksrv" manages a database containing icon and application data for the entire EtherShare server, and file and directory ID information for network volumes. The database data is contained in the ".Desktop" file in the root directory of each HELIOS volume. The file name ".Desktop" is protected by EtherShare, and is usually invisible to Macintosh users.

The application data records in each ".Desktop" file contain the information required to assign documents to the Macintosh applications that created them. The Macintosh Finder uses this information to start the corresponding application when the user double-clicks on a particular document. Each time a new application is copied into a HELIOS volume, "desksrv" creates a new entry in the corresponding desktop database file.

The icon data records in each ".Desktop" file contain icons from all the applications in the volume, sorted by type and creator codes.

In order to let the Finder display icons for documents and applications, each application contains icon images (bitmaps) for its own icons in several sizes and styles, and icons for all the document types it can create. For example, Microsoft Word can create text, glossary, dictionary documents, etc., each with its own icon. Each icon is associated with unique file type and file creator codes. The application's documents normally contain the file type and file creator codes only (stored in their resource forks), but no icons. See "Directory and file formats" in the HELIOS EtherShare manual for more information.

Each time a new application is copied into a local Macintosh volume, the Finder copies all of the icons it contains to the volume's desktop file. In the case of EtherShare, the desktop server stores them in the ".Desktop" database file, after checking that the same icons are not already stored there.

If you copy documents of an application to your Macintosh without ever having owned the corresponding application, then the icons may appear blank. This is because the icons you see in the Finder are taken from the desktop file and not from the documents, the latter simply supply the correct type/creator codes.

Files created by UNIX applications do not have a resource fork. In such cases, EtherShare normally assigns icons to them automatically. See "Directory and file formats" in the HELIOS EtherShare manual for more details.

When the Finder or an application needs to open a file, in addition to looking for the specified file name in a named directory and volume, a system option is available to open the file by a reference number instead. This reference number is called the "file ID". The directory path can be specified by its "directory ID", too. By using file and directory IDs, files can still be found after a user has renamed or moved them. This provides Macintosh users with a lot more flexibility than Windows users, for example.

Each ".Desktop" file contains file and directory IDs for all the files and directories in the volume. The file ID is also stored in each file's resource file; the directory ID is also stored in each directory's resource file.

The file and directory IDs are allocated when the file or directory is first created, and never change even if the file is renamed or moved to another location in the same volume. The IDs are normally invisible to the user.

After a period of time, each volume desktop file tends to collect a number of icons which are no longer needed, since the corresponding application has been deleted from the volume. For this reason, you may rebuild your desktop from time to time, i.e. start a process which scans the entire volume for applications and makes sure that the desktop only contains icons for existing ones.

To rebuild the desktop of a HELIOS volume, you must make sure that the volume is not mounted (e.g. with the Active Users option described in 6.5.6 "Active Users" and then start the Admin program on one of your Macintosh clients, select the volume in the volume list, and choose Rebuild Desktop from the Volume menu (see "Volume menu" in HELIOS Admin).

The rebuild process will always add files to the desktop database in order to allow file name searches in the volume desktop database. This requires that a resource for every file/folder is available.

During a desktop rebuild, missing resource directories and resource files are automatically created for all directories in the HELIOS volume (including the volume root directory); existing directory IDs are verified and missing ones are created.

Also, missing file IDs are created and existing file IDs are verified. Missing resource files are created as well. The file type in that case, is substituted by a dummy, e.g. "UNIX/UNKN". The generic UNIX icons and extension-mapped icons are created later by the File server, when the corresponding folder is first opened.

Note that a desktop rebuild and the creation of missing resource files may cause difficulties if you try to access these files from an EtherShare 2.6 (or older) server via NFS. Old EtherShare versions cannot display such files properly; the icons are displayed blank. Therefore, you should make sure that in a multi-EtherShare-Server environment, all servers are updated to EtherShare.

By default, the "rebuild" program uses two passes to update the volume desktop database. The two pass approach does have the benefit that on volumes where duplicate file/folder-IDs exist (usually resulting from manipulations of files/folders by UNIX commands), files/folders will get an adjusted ID only after the complete desktop is verified, and all other objects will retain their original ID.

File and directory IDs are stored in both the ".Desktop" file and the file's (or directory's) resource file; if the verification detects differences, the IDs from the resource files are assumed to be the correct ones.

While a rebuild is running, it is possible to write to a HELIOS volume. As long as the desktop database is not yet complete, changes to files or folders may result in different file-/folder-IDs issued for objects not yet re-enumerated by "rebuild".

To prevent inconsistencies between information stored in the desktop databases of an HELIOS volume and the files/folders in this volume, the rebuild process encountering an RPC (Remote Procedure Call) timeout will exit immediately. Desktop information for this volume will be incomplete until a rebuild finished successfully.

In case "afpsrv" processes also encounter RPC timeouts, the volume will get secured against write access and will be grayed out in the Connect to Server volume list. Opening folders and reading files will still be possible, but creating/renaming/moving files or folders will not be possible any longer. Not even trashing files/folders will be allowed.

RPC timeouts are symptoms which are usually caused by high server or I/O load, slow I/O devices, network or communication problems. Assure that the cause of this problem is solved before restarting HELIOS services. Depending on the severity of the problem, it may be necessary to stop and restart HELIOS services on the server by using the scripts "HELIOSDIR/bin/stop-helios now" followed by "HELIOSDIR/bin/start-helios".

In the case of files created by UNIX applications, the resource directories are unnecessary - although they do not affect UNIX applications which access the original files, they take up a certain amount of disk space. Accordingly, it may be better to organize your directories and volumes with separate file systems for UNIX-only and Macintosh files.

Important: We strongly recommend to use the "rebuild" program to put your desktop in order (see 7.10 "rebuild"), or to use the Rebuild Desktop feature in HELIOS Admin. Never delete the desktop database under UNIX!

Each time you open a HELIOS volume with the Connect to Server dialog, the desktop server checks the logical consistency of the desktop file and may trigger a desktop rebuild if it finds invalid information. This process takes place automatically and in the background. The same check is done also for each volume - according to the setting of the AFPPublish and SMBPublish volume flags in the "Preferences" file - when HELIOS is first started.

Most computers such as the Sun SPARC and IBM RS/6000 use the so-called Motorola byte order, and others such as the HP Alpha and IBM Linux use the Intel byte order. An auto-rebuild also takes place if you mount a volume whose desktop was created by a computer with a different byte order.

Furthermore, the volume's directories must not overlap or include the directories of other HELIOS volumes. You should choose the volume mount point carefully to make sure this does not happen. To avoid problems, EtherShare checks for overlapping volumes; volumes will be grayed out if they overlap a volume you have already mounted. You will receive an error message (see later). HELIOS Admin will check for overlapping volumes as well. Nevertheless, it may happen that existing volumes are not checked and that you are able to create a new volume that overlaps an existing one.

In the case of CD-ROM volumes which have been mounted with HELIOS Admin as "read-only", the desktop server first checks to see if a valid ".Desktop" file is available on the volume's root. This can be the case, for example, for MO cartridges which were previously mounted under EtherShare as "read-write", allowing a valid desktop to be created.

If a valid ".Desktop" file cannot be found (this will almost always be the case for CD-ROMs), the desktop server creates a temporary desktop file in the host's "/tmp" directory using a unique file name starting with "desksrv-". Since the files on the CD-ROM almost certainly have no resource forks in this case, the Finder will use the information that are available in the extension mapping table or show one of the about 20 generic EtherShare icons.

"afpsrv" or "pcshare" will try 6 times for 5 seconds each to reach the desktop server "desksrv" to retrieve or store information from/to the desktop database of its volumes. Although even the older values were a very long time for network or RPC connections, we decided to even extend these values.

If the server does not get a response from "desksrv" during this period this indicates a severe problem with the underlying UNIX operating system, UNIX file system or RAID/HSM drivers, or a hardware problem related to SCSI or hard disks.

To prevent inconsistencies between information stored in the desktop databases of a HELIOS volume and the files/folders in this volume, the "afpsrv" client process encountering this timeout will secure this volume (all mounted volumes) against write access. Opening folders and reading files will still be possible, but creating/renaming/moving files or folders will not be possible any longer. Not even trashing files/folders will be allowed.

Apart from the usual messages issued in the host system error log, the server will issue an error message on the client if the communication to "desksrv" fails, and inform users that the volume falls back to "read only" access. The message is:

Though this message is issued by one "afpsrv" client process only, it is likely that all other "afpsrv" processes may encounter the same problem and therefore, the UNIX system administrator should be notified immediately.

Since applications usually work with temporary files/folders, it may not be possible to save single files. If this problem was only temporary, unmounting all HELIOS volumes and remounting them will make these volumes writable again. If not, this was no temporary problem and is not solved in the meantime the Macintosh Connect to Server dialog will show no volumes at all. Not even "root" will be able to mount any of these volumes.

Depending on the severity of the problem, it may be necessary to stop and restart the HELIOS services on the server by using the scripts "HELIOSDIR/bin/stop-helios now" followed by "HELIOSDIR/bin/start-helios".

HELIOS Base UB User manual