6 The EtherShare file server

This chapter is devoted to the EtherShare file server. The function, the configuration and the operation of the file server is described. Information is included to allow the administrator to set up users, groups, and volumes, create folders, and define access privileges. Finally, we describe methods with which data in the file server volumes can be archived to mass storage.

6.1 The file server program

The EtherShare file server system is contained in "afpsrv". It is copied to the "HELIOSDIR/sbin" directory during the installation. The server is usually configured to start "afpsrv" automatically when UNIX is booted.

Note: EtherShare "afpsrv" uses the default port 548. On Mac OS X, if the native OS X AFP services are already running on this port, EtherShare uses a random free port. See the note adjacent to afpport in 13.1 "AFP server preference keys" for instructions on how to assign a certain free port number for "afpsrv".

"afpsrv" is the program that implements the AFP (Apple Filing Protocol) file server functions. It waits for filing requests from the AppleTalk or TCP/IP network, which are then immediately processed. Each new login request results in a separate "afpsrv" process being created. Accordingly, when a number of users access the file server at the same time, a number of "afpsrv" processes run on the host simultaneously. "afpsrv" is capable of supporting the following modern features:

Features introduced with AFP 3.1 (EtherShare UB):

Feature	Description
Directory enumerations	AFP 3.1 does faster directory enumerations
Long file name support	File names can contain up to 255 characters
Unicode/UTF-8 support	All names for users, groups, volumes, and servers are Unicode/UTF-8 based and are compatible with HELIOS Unicode/UTF-8 volumes. ":hex" volumes are disabled for AFP 3.1. For AFP 2.2 clients (Mac OS 8/9) the Uniciode/UTF-8 encoding is transformed back into the client encoding specified by the AFP charset in the volume settings.
UNIX ownership & permissions	AFP 3.1 utilizes UNIX users and groups and uses UNIX permissions for files and folders.
Mac OS X symlink support	This feature allows copying application packages to/from the server, without loss of information.
Mac OS X client sleep support	Disables connection traffic during sleep (no immediate time-out). Users using "Energy Saver" features (no connection time-out).
Client/Server reconnect support	The Client/Server reconnect support allows automatic reconnection on network time-outs or failures as well as on server failures (good for high availability). In case of a reconnection, all open files are closed and re-opened.
Very large files (64-bit file offsets)	With AFP 3.1, very large files up to millions of terabytes can be handled. The support of file sizes that large is needed e.g. for large PrePress jobs, video data and backup archive files. This was not possible with the 2/4 GB file size limit of AFP 2.2.

A file in the Windows/NTFS environment can have a certain number of file streams. File streams contain meta data such as creation or modification date information, icon information, etc., similar to the resource fork of a Mac file. If you manipulate files which have been created in a Windows/NTFS environment, "afpsrv" supports file streams (see NTFS file streams support in the Base manual).

Note: The number of concurrent connections to HELIOS services via AppleTalk is limited to 250. To establish more than 250 connections at the same time use AppleShare IP, instead. See sessions in 13.1 "AFP server preference keys".

You can specify both a welcome message and a shutdown message to be output on Mac workstations when they log in to EtherShare. There are no preferences to set for this feature. Instead, create two text files "login.msg" and "shutdown.msg", and store them in the "MacOS" folder of the "HELIOS Applications" volume. The messages will then be used automatically by the file server during login and shutdown. Usually, only the administrator has write privileges to this directory (volume).

For example, the two messages could be: "Welcome to the Support server of HELIOS Software GmbH" and "The Support server of HELIOS Software GmbH has now been shut down".

Note: If you are running a demo copy of EtherShare on your server you cannot alter the default welcome message.

A maximum of 199 characters will be displayed (excess characters are truncated). If you want to include national accented characters such as Umlauts in your messages, use TeachText to write them: since the Umlaut codes are stored here in Mac binary format, it is a lot of work to enter the right codes with a UNIX editor.

Mac OS 9 has no support for AFP 3.1, AFP 2.2 is used instead by Mac OS 8/9 clients. As a result, file/directory names containing more than 31 characters will be truncated. In this case the file name, beginning with the 26th character, is replaced with a hashmark ("#") followed by a four hexadecimal character checksum. It is possible to rename these files to a different file name from Mac OS 8/9. Working on the files with the truncated names is not recommended though.

6.2 Directory and file formats

On UNIX machines, the EtherShare file server simulates the Mac's HFS (Hierarchical File System) on the UFS (UNIX File System); the latter is found in many UNIX variants. Due to the differences between these two systems, the same Mac file appears differently when it is viewed through the UNIX file system compared to when it is viewed from a Mac workstation.

In EtherShare, each HFS volume is mapped to a specified part of the UNIX file system and mounted at a specified directory. This directory is then the root directory of the volume.

You specify the volume mount point when setting up new volumes with HELIOS Admin.

In contrast to files under DOS and UNIX, all Mac files are associated with so-called "Finder info" contained in the file's directory entry, which stores among other things the file type and creator, the file creation date, etc.

Each file is split into two parts, the "data fork" and the "resource fork". This "split" is normally invisible to the Mac user; the "Finder info" in the file's directory is also invisible.

The file type and creator are used by the Finder to select the right icon to display. They are each 4 bytes long. The file creator is also used to automatically find and start the corresponding program when you double-click on the icon of a document. The icons themselves are stored in the desktop file, which exists only once for each volume. Each application is usually associated with a single file creator code (e.g. "MSWD" for Microsoft Word), but can as well have several file type codes (e.g. "WDBN" for normal Word documents, "WHLP" for Word help files, "DCT5" for the Word dictionary, etc.). See Icon data in "The desktop server" in the Base manual for more information.

Under EtherShare, the file's data fork is stored with the chosen file name in the UNIX directory corresponding to the folder.

The file's resource fork is combined with the Finder info and stored in a separate "resource file" of the same name in the so-called "resource" directory, which is the ".rsrc" subdirectory of the folder's directory.

The first 512 bytes of the resource file are used for the Finder info (bytes 0-511), and the file's resource data starts at byte 512. Files created by UNIX applications have no resource fork, and the EtherShare resource file (if present) may then be between 64 - 512 bytes, this is normal. A description of the resource file structure is available on the HELIOS website.

Mac file names which are invalid for UNIX are converted according to a specified algorithm.

When you create a folder under EtherShare, which you do with the Finder in the normal way, a UNIX directory is created with the same name as the folder. Folders, too, have Finder info, which stores among other things the folder's window position and size and the viewing style (Mac OS 9). The Finder info for a folder is stored in the parent's folder "resource" directory, which is created automatically when the folder is created. See Creating new folders under UNIX in 6.5 "Access privileges" for related information.

Assumed you have a file "Test" in folder "Demo" which is in "dave's" home volume. Under UNIX you will have:

/home/dave/Demo/Test file's data fork
/home/dave/Demo/.rsrc/Test file's resource fork
/home/dave/.rsrc/Demo folder's Finder info

Furthermore, if for example the volume mount point is
"/home/apps", the volume desktop is contained in the UNIX file "/home/apps/.Desktop". The "Network Trash Folder" for the volume is contained in the UNIX directory "/home/apps/Network Trash Folder" and in the file
"/home/apps/.rsrc/Network Trash Folder". Finder info for the root of the volume (viewing style, layout info etc.) is contained in "/home/apps/.rsrc/^^volrsrc". See "The desktop server" in the Base manual for related information.

The file names ".Desktop", ".DeskServer", and the ".rsrc" folder are protected by EtherShare, and cannot be accessed from a Mac client.

Inside a HELIOS volume, ".rsrc" directories can only be missing if folders were created manually from UNIX or if ".rsrc" folders were removed manually from UNIX. "afpsrv" automatically creates missing ".rsrc" directories for every folder opened from the Mac in case a ".rsrc" directory is available in the volume root directory of the HELIOS volume. This applies to files as well; if ".rsrc" folders are available, resource files inside the ".rsrc" folder will be created automatically.

HELIOS volumes store Mac native files (including resource forks and Finder info) and Windows native files (including NTFS streams) in a format compatible with the server file system. When file operations are performed via EtherShare or PCShare clients, all of the associated file components are transparently acted upon, and the volume desktop database file (".Desktop") is updated. Hence it is always recommended to perform file operations from HELIOS clients. In situations where it is necessary to manipulate files in HELIOS volumes directly on the server, it is essential to use the HELIOS "dt utilities", instead of the corresponding UNIX commands. The "dt utilities" will properly perform the file operations, and should be used for all command line operations, in automated scripted workflows, for restoring backups, etc. Refer to the HELIOS Base manual for details.

Provided that the UTF8 preference is set to TRUE (which is the default setting, compare "Volume preference keys" in the Base manual), special characters such as "ä" can be used on different platforms (Mac and PC clients) because under "Unicode/UTF-8" they are 8-bit encoded. Exceptions are the "/"-character, which is translated into a particular sequence which consists of the caret (^) and two following characters representing the hex value of the character (^2F).

In a non-UTF-8 volume, Mac special characters are automatically translated by the EtherShare file server into a three-character escape sequence, but in this case led by a leading colon (:) instead of the caret (^). For instance, the special character "ä" is translated into ":8a".

However, accented characters (Umlauts) are not recommended for user names and passwords (otherwise you will need to remember different passwords for Mac and UNIX logins). Your UNIX host name must never include a slash character (for example "my_rs/6000").

Note: Non-UTF-8 volumes are only supported in Mac OS
8/9. UTF-8 volumes are supported in all Mac OS versions.

It is not possible for an AFP 3 Client to mount a non-UTF-8 volume in the Finder from the EtherShare file server. Any attempt will fail and the following message is written to the syslog file:
"<volume_name> without UTF8 support, disabled for AFP 3 clients".

Finder info for UNIX files (which do not have and do not need resource files) are simulated automatically as "generic icons" by EtherShare. EtherShare automatically recognizes about 20 UNIX file types (e.g. shell script, socket etc.), and simulates the Mac file type and creator even if the folder has no resource directory. If the resource directory is already present, EtherShare will create a suitable resource file, too, when the corresponding folder is first opened. The resource file will be ignored by UNIX applications, but allows EtherShare to recognize the file type immediately the next time the folder is opened. EtherShare also recognizes TIFF and EPSF files, but it cannot automatically create the PICT resource for EPSF files. The following special UNIX file types are recognized directly (the type and creator codes are shown as well):

Description	Type	Creator
Block device	BDEV	UNIX
Character device	CDEV	UNIX
Socket	SCKT	UNIX
Named pipe	PIPE	UNIX

With normal UNIX data files, the file server tries to determine the file type by examining the first 512 bytes of the file, in order to place it into one of the following groups:

Description	Type	Creator
Executable file	EXEC	UNIX
Executable SCRIPT file	TEXT	UXSC
Object file	OBJ_	UNIX
Archive file	AR	UNIX
CPIO archive file	CPIO	UNIX
Lempel-Zev compressed file	COMP	UNIX
Huffman packed file	PACK	UNIX
SUN raster image file	RAS_	UNIX
PostScript file (including EPS)	TEXT	UXPS
Mailbox file	TEXT	UXMB
TIFF file	TIFF	UNIX
Gnu ZIP file	Gzip	UNIX
PDF file	PDF /TEXT	CARO
EPSF file	EPSF	UNIX

Note: Each passed creator or type must be exactly 4 bytes long.

If the UNIX file does not correspond to any of these types, a differentiation is solely made between either text or binary data files. A binary data file is defined as a file where at least 30% of the characters are not contained in the 7-Bit ASCII code. All other files, including empty files, are classified as type TEXT. Accordingly, the following two file types should be added to the above list:

Description	Type	Creator
Text file	TEXT	UNIX
Binary data file	DATA	UNIX

If the user does not have sufficient access privileges to read a particular file, the file is classified as type NOPE:

Description	Type	Creator
No permission	NOPE	UNIX

If a file cannot be read by a particular user because a physical read error has occurred, the file is classified as type unreadable:

Description	Type	Creator
Unreadable file	????	UNIX

After determining the type, each UNIX file is assigned one of about 20 different icons by EtherShare (Fig. 24). This allows Mac users to easily differentiate between files created under UNIX (all icons include the name "UNIX") and normal Mac files.

Note: If a file type is assigned the code "UNKN/UNIX" the file server automatically enforces a file type conversion.

If necessary, the generic icons feature can be disabled (see binonly in 13.1 "AFP server preference keys"). In that case all UNIX files are classified as binary data files (DATA/UNIX).

Fig. 24: Generic icons for UNIX files on EtherShare

You can also assign suitable icons to non-Mac files by using the Extension Mappings feature in HELIOS Admin (Lists menu). This option is particularly useful if you are also using Windows networking software, such as HELIOS PCShare, on your server, since under Windows the file name extension is typically used to indicate the file type.

UNIX file types such as: Mailbox, Text, and Shell Script can be edited using a Mac text editor.

The file server will recognize EPSF files and will apply the type "EPSF" and creator "UNIX" to these files (for more information regarding the recognition of PC-created "*.eps" files, see "Extension Mappings" in the Base manual). The icon is the same as used for plain PostScript files. In older EtherShare versions, these files were recognized as PostScript only and were classified type "TEXT" with creator "UXPS". Since these resources were already created, the creator/type combination will not be changed for existing files. This applies only to files stored on the server by UNIX or Windows applications, Mac files supply their own type and creator.

An automatic recognition feature for Adobe Acrobat PDF files allows easy access to HELIOS documentation provided in PDF format, e.g. on the HELIOS distribution CDs and the folder "Documentation" in the "HELIOS Applications" volume. You can mount our distribution CD on a UNIX server, on a Mac, or on a DOS/Windows PC, and open the contained PDF files with Acrobat Reader/Acrobat Exchange on any of these platforms.

The EtherShare file server supports file and record locking between Mac workstations. Likewise, PCShare - a TCP/IP-based Windows networking product developed by HELIOS - supports file and record locking between Windows workstations. Locks of both file servers are shared by accessing the same "locktable" file which is in the "HELIOSDIR/var/run" directory. Hence, if a volume is shared by both EtherShare and PCShare, cross-platform file and record locking is enabled.

The "UNIX Sharing" option has to be switched on, however, to enable file locking.

Note: Not all applications honor file and record locks.

"afpsrv" supports UNIX (advisory) locking in addition to the built-in Apple AFP-compatible (mandatory) locking.

Check with your supplier of UNIX applications whether these do also support and use advisory locking before you use Mac/PC-based applications accessing files concurrently with UNIX based applications.

If you are using NFS-imported file systems for EtherShare or PCShare volumes the "lockd" and "statd" daemons must be configured and running. See your NFS documentation for further details.

Please note that symbolic links pointing to directories in- or outside the current volume would confuse the file server, and are therefore not displayed. For example, two directories in one volume might have the same directory ID.

A double-click on one of the folders then could open the other. If you need links, use the Mac Make Alias function instead.

6.3 Users and groups

User and groups are authorized by use of the HELIOS authentication server. Details on the authentication server can be obtained in the Base manual.

Users that are not registered in the system but still need access to the network from time to time can log on to the file server as a guest. The administrator can configure EtherShare to either accept or reject guest access.

During logging on, guests are not required to enter either user name or password. Guests only have access to public volumes, and do not have a private volume. If necessary, guests can be denied access to specific public volumes by suitably configuring the access privileges of the volumes.

Although guest users do not need to enter any user name, guest access must still be declared in the "Preferences" file via the guest preference (see "Authentication server preference keys" in the Base manual), in order to allow guests group membership.

In order to ensure that guests do not have access to protected applications or documents of other users, the administrator should assign the guest a primary group which has no other members. Folders and files are protected against access by guests as long as access for the user category "Others" has been explicitly disabled.

Since user volumes are only available for registered users, a home directory for guests is ignored by the file server.

6.4 Public and private volumes

A volume (a Mac file system) can be stored both on a removable disk or on a hard disk. A hard disk can also be subdivided into several volumes, i.e. several separate file systems. The file system used by Mac computers is called HFS (Hierarchical File System) or HFS+, respectively.

The UFS (UNIX File System) is able to use storage capacity which is available through the network remotely in another computer via NFS (Network File System). Such remote storage can also be used by EtherShare. This allows any computer which supports UFS (e.g. many computers running a UNIX variant) to store volumes for an AppleTalk network.

Under EtherShare, the UNIX file system can be treated like an Apple hard disk: one or more volumes containing folders and files can be mounted at a particular UNIX directory and made available to a group of users.

Volumes can be set up by using "prefvalue" (see "HELIOS utility programs" in the Base manual), but we strongly recommend that you do this with HELIOS Admin instead.

Note: Please see 3.3 "Volume AFP settings" for related information, especially if you are using file systems mounted remotely through NFS.

When a volume is created, it is automatically available to all users/groups. Such volumes are called public volumes (even if not all users/groups have the right to access them). Public volumes can optionally be protected with a password.

During the installation the public volume "demovol" is created. The installation program also creates a volume "HELIOS Applications" in "HELIOSDIR/public". It is used for programs such as HELIOS Admin and HELIOS LanTest.

If you only want access to user volumes, and not public volumes, just set the Guest preference to FALSE (see "Volume preference keys" in the Base manual). No other configuration changes are necessary.

Each time you log on to EtherShare, if a home directory has been specified, you are automatically assigned a private "home" volume by the file server. The name of the home volume is shown abbreviated on the Mac workstation by using the tilde ("~") character together with the user name (e.g. "~david"). It can be used to store the user's private files.

If a particular user should only be allowed access to public HELIOS volumes, and not be assigned a home volume, when creating the user you can leave the home directory field empty in HELIOS Admin (which is equivalent to omitting the home directory entry in the system file "/etc/passwd"). This may - depending on the UNIX system - disable the login to the UNIX shell, but is not the same as unchecking Macintosh visible in the Volumes:~ window in HELIOS Admin, which simply makes home volumes invisible to (all) Mac users.

"afpsrv" checks very extensively for overlapping HELIOS volumes during each mount request. If an already mounted volume does include (or is included inside) a volume to be mounted, this will be invisible in the Connect To Server- dialog and an appropriate system error message, which contains the names of the overlapping directories, will be logged from "desksrv".

Please make sure that no single public or private HELIOS volume overlaps any other HELIOS volume.

If in doubt, please consult your HELIOS dealer to implement a safe volume configuration.

The conversion of file name encodings in a private volume (home volume) from old-style ":Hex" to Unicode can be done according to the instructions given in 12.9 "converthome".

Volume names must be unique. If the user or administrator defines the same volume name more than once, the entry encountered last during user logon is ignored, since no two volumes on the file server can have the same name. Otherwise, it would not be possible for workstations to uniquely access a particular volume. The new volume must be given another name.

If the administrator installs a new public volume and a user has already installed a private volume of the same name, the latter is no longer available in the Connect To Server- dialog when the user logs on to the file server the next time. In such cases, the private volume must be renamed before it can be used again.

The administrator should be particularly careful not to create a volume with the same name as a user's home volume (e.g. "~rita"), because the user will then no longer be able to access their home volume any more.

The maximum number of network volumes that can be opened by Mac users on the file server simultaneously is normally 128. Each open volume is only counted once, even if it has been opened by more than one user. See maxdesktop in "Desktop server preference keys" in the Base manual.

The file server supports automatic mapping of file name extensions. This simplifies file sharing between EtherShare, UNIX and PCShare, by simulating an appropriate Mac type and creator, allowing Mac users to open files created under Windows or UNIX with a double-click.

Note: This feature allows you to allocate specified file name extensions to icons of applications or documents which already reside on the file server, but it does not allow you to create new icons.

The file "HELIOSDIR/var/conf/suffixes" specifies the required mapping, which has the following structure:

'TEXT' 'KAHL' .c
'TEXT' 'KAHL' .h
'TEXT' 'MSWD' .txt
'TEXT' 'MSWD' .doc
'TEXT' 'XCEL' .wks
'TEXT' 'XCEL' .wk1
'TEXT' 'XCEL' .wk3
'XL58' 'XCEL' .xls

EtherShare recognizes EPSF files and will generate type "EPSF" and creator "UNIX" although the icon will be the same as for UXPS/TEXT files. CR/LF conversion is not provided for UNIX/EPSF files. Extension mapping can be defined by editing the "suffixes" file, or by means of HELIOS Admin (see "Extension Mappings" in the Base manual).

6.5 Access privileges

Access privileges - under UNIX called "permissions" - define which users are allowed to work with which folders and files. Access privileges are assigned by the administrator or the owner of a file or folder.

6.5.1 HFS access privileges (Mac OS 9/AFP 2.2)

Under Apple's HFS (Hierarchical File System), no access limitation mechanisms are available for individual files, because the concept of user authorization is not known. A file can only be "locked" (write-protected) to prevent unintended writing/deleting operations. This attribute, however, can be disabled by any user at will. Furthermore, write-protection is not available for folders.

In a file server environment, considerably more sophisticated access privileges mechanisms are necessary. Apple's AFP specification for sharing files differentiates between four different types of privileges:

This attribute specifies whether a particular folder is visible to the user. If a particular file is visible it can also be read.

This attribute additionally allows modifications applied to the files in the folder.

Any form of access to that folder is denied, i.e. neither reading the contained files, nor applying changes to them is possible. See Fig. 28.

Read and/or write permissions can be set for the file owner, group members, and others.

Historically, using AFP 2.2 to access server volumes, it was not possible to specify different access privileges for individual files in the same folder. This is still true for Mac OS 8/9 clients, which use AFP 2.2. If it is necessary to allow a user to change a particular file, but not change another file, the two files need be stored in separate folders. If this is not possible, your only choice is to use the UNIX "dt chmod" command to change the privileges for individual files on the server. While AFP 2.2 does not allow granular control of access rights, it does facilitate file sharing and collaboration.

Using HELIOS AFP 3.1 smart permissions, files saved to the server inherit the permissions of the parent folder. This is the preferred option for workgroup file sharing. When this option is active, the Finder of Mac OS X clients is not allowed to change access privileges for individual files. However, changing access modes from the Finder can be toggled on/off as described below.

When "Smart permissions" are not active, server volumes will use UNIX permissions. UNIX command line utilities in AFP volumes will create files according to "umask" and work as expected. However, many Mac OS X GUI applications create all new files and directories with default permissions of:

So, UNIX permissions has the advantage of easier to change permissions, but the disadvantage of default permissions that are not optimal for file sharing and collaboration.

Extreme care should be taken when changing access privileges of AFP files from the UNIX server directly (do not forget the resource part) or, in order to avoid such problems, use the "dt chmod" program. Incompatible combinations of privileges could lead to EtherShare access problems. For example, it may not be possible to read from or write to a file anymore, or it may no longer be possible to use a folder.

6.5.2 EtherShare privileges (Mac OS X)

Mac OS X is a UNIX-based operating system, so AFP 3.1 file/directory access permissions are identical to the UNIX permissions. However, HELIOS AFP 3.1 supports two (mutually exclusive, serverwide) permissions modes for saving files and folders: HELIOS AFP 3.1 smart permissions; and UNIX permissions. As mentioned above, the default setting is to use smart permissions, so that files saved to the server will inherit the permissions of the parent folder. When smart permissions are turned off, standard UNIX permissions will be used when saving files and folders. See useunixperm in the Base manual.

With enabled UNIX permissions (useunixperm=TRUE), permissions can be changed using the Get Info dialog from the Mac OS X Finder as usual.

With disabled UNIX permissions (useunixperm=FALSE), which is the default, permissions cannot be changed directly. This feature is only available with active UNIX permissions. However, to allow an authorized user to change the permissions, do the following:

Open the Finder's Get Info dialog for a file/folder in the server volume. Then open the permission details, enter the new user name unixperm and press the TAB key.

A Finder message pops up ("invalid user name"), together with the following AFP message (Fig. 25):

Fig. 25: Enable UNIX permissions

Now the UNIX permissions are enabled for the AFP server client process, irrespective of the volumes' smart permissions status, so you can change the permissions as required.

The owner can change the read/write mode within the Finder for owner, group and others.

Note: AFP 2.2 allows the owner of directories to transfer the ownership to a different user. AFP 3.1 does not support changing the owner unless you are the user "root".

The UNIX permissions for the particular client are enabled until the client disconnects from all server volumes or the UNIX permissions are switched off. Switching off the UNIX permissions is done by entering the user name reset in the Get Info dialog, followed by pressing the TAB key. Then again, a Finder error ("invalid user name") pops up, together with the following AFP message (Fig. 26):

Fig. 26: Reset permissions to volume default

As discussed earlier, a folder in a volume is represented as a directory in the UNIX file system, which is also associated with a (normally invisible) resource directory. The EtherShare file server uses the resource directory to store the Mac's resource fork and the Finder info for the files.

If it is required to create a folder directly from UNIX use the "dt mkdir" program, so both the main and the resource directory will be created. The "dt chown" and "dt chgrp" commands are used to set the owner and group of the folder.

# dt mkdir Folder
# ls -ld Folder Folder/.rsrc/
drwxrwsr-x 3 root root 512 Jul 20 16:01 Folder
drwxrwsrwx 2 root root 512 Jul 20 16:01 Folder/.rsrc/
#

Please refer to the UNIX system documentation for more details of the "mkdir", "chown", "chgrp", "chmod", and "ls" commands. Also refer to the "dt mkdir", "dt chown", "dt chgrp", "dt chmod", and "dt ls" commands in the Base manual, respectively.

We recommend that network folders are always created by using the Finder on the Mac, in the same way as local folders, since this guarantees that all of the above considerations are handled automatically.

A folder can be deleted in an analogous way, by using the UNIX command dt rm -r, provided that the user has sufficient privileges. If the folder contains further folders and/or files, these are also deleted.

IBM and Sun operating systems set or clear the "setgid" bit on directories to indicate whether files created in that directory should follow BSD semantics or System V semantics, respectively. The "setgid" bit is then automatically propagated to nested directories. AppleShare users expect the BSD style, thus HELIOS Admin ensures that the "setgid" bit is set if it creates a directory for a new volume or a new user. The "dt" utility will automatically make sure that the "setgid" bit is set.

6.5.3 EtherShare privileges (Mac OS 8/9)

The four modes of privileges are separately defined for four categories of AFP users: the owner of the folder ("Owner:"), group members ("User/Group:"), all other users of the system ("Everyone", equivalent to "Other" under UNIX), and the administrator. This allows access privileges to be individually tailored. With the exception of the administrator, the owner of a folder is the only one who is allowed to change the privileges of the folder (if necessary, you can allow "Owner:" to be any user, by just leaving the field blank).

The folder is visible and all files can be read, changed and deleted. New files and folders can be created.

The folder is visible and all files can be read. Amendment or deleting of files is not allowed. New files and folders cannot be created.

The directory content is not visible and files in the folder cannot be read, amended or deleted. However, new files and folders can still be created since the folder acts as a drop folder (Drop Box).

Access to the files and folders is not possible. New files and folders cannot be created and the folder cannot be deleted.

The following table shows the four combinations of access privileges for the EtherShare file server, and the corresponding rights in the UNIX file system. Remember that the files which are stored in the folders have always the same access privileges as the folders themselves.

Read & Write (rw-) read write execute
Read only (r--) read execute
Write only (Drop Box) (-w-) write
None (---)

Note: The System V UNIX semantics use "x" on directories, whereas "s" provides an additional bit in BSD UNIX for setting group IDs. For more detailed information see also Creating new volumes under UNIX below. You may also refer to your UNIX documentation.

The Finder's sharing section (in File > Get Info > Sharing-) can be used to display and edit the access privileges. Fig. 27 shows the privileges for a folder.

Fig. 27: Folder access privileges

The corresponding directory listing for this folder, made with the UNIX program "ls" is:

# ls -ld adi adi/.rsrc
drwxrws--- 3 hendrik helios 512 Jul 20 16:16 adi
drwxrws--- 2 hendrik helios 512 Jul 20 16:16 adi/.rsrc/
#

Only the folder's owner or the system administrator ("root") can change the access privileges of the folder. The corresponding fields and checkboxes are grayed out when another user asks for privileges information (Fig. 28).

Fig. 28: Access privileges for user not being the owner

6.6 EtherShare compatibility notes

When compared to the AppleShare file server using HFS, EtherShare has a few minor limitations but also offers powerful additional features which result in part from specific features of the UNIX environment on which EtherShare is based.

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

Fig. 29: Operating systems and the case-sensitivity of file names
	Preserve case-sensitivity	Ignore case-sensitivity
Mac OS X (HFS default)	•	•
Mac OS X (UFS/Xsan)	-	•
Mac OS 8/9	•	•
UNIX	•	-
MS-DOS	-	•
Windows	•	•

As Fig. 29 shows, there is no case preserving under MS-DOS, i.e. file names entered in lowercase will appear uppercase in the directory listing. In contrast to UNIX, the Mac (as well as Windows) 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 is not true for HELIOS volumes. This distinction is normally not a problem - if an application has created a file called e.g. "Editor Prefs", and needs to open the file again, it usually tries to open it using the same name and not under the name "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 link (alias) or by renaming the file. Contact your application vendor for assistance.

When renaming a file, EtherShare does check whether the new name already exists. E.g.renaming a file "copy.txt" to "copy.TXT" does succeed because the HFS+ file system is not case-sensitive. On other platforms this fails because the other UNIX file systems are case-sensitive.

You will get a file system error if you try to copy files whose names contain ASCII "0" (zero) to the server, or if application programs or tools try to create such files. This restriction also applies to all AFP compatible file server products (including those from Apple).

EtherShare UB+ User manual