Technical notes

Standard OS-9 Utilities
File permissions
File Names
File Locking
File Buffering
File descriptors
File times
Memory usage and possible limitations
Multiplexing (Version II)
Printing (Version II)
Windows Server 2003 notes
Quick Reconnect

Standard OS-9 utilities
The only commands that do not work with Samba File Manager are thoses needing information about physical layout of the mounted disk, which are dcheck, format, os9gen, fsave, frestore, backup.

The attr utility works, but there are some limitations due to the nature of server's file system, which can be as old as Microsoft DOS. The only file attribute you can change is S_IWRITE on the client's side, so on the server's side the file will be marked as read-only.

The Microware's rename utility opens the file to be renamed with the access modes as 3 (i.e. S_IREAD|S_IWRITE). On the other side, Samba servers cannot rename opened files. I hacked rename code to make it open files with access modes as 0, but due to the copyright problems cannot distribute the modified version to all the world. If you need this functionality, contact me via e-mail for instructions.

There is the incompatibility between standard OS-9 utility deldir and Samba File Manager. Sometimes the command fails with an error E_FNA at random directories. Because File Manager has to emulate OS-9 file descriptors, they are virtual and can vary from session to session. In this case deldir cannot determine right directory structure (because it is very dumb and internally uses, just forks, standard dir -ea utility). As a workaround, there is the analogous utility, named rm, which was found on os9archive with no copyrights, and modified by me. It works as on Samba networked filesystem, so and on OS-9 local filesystem with no errors.

In compare with Microware's PCF (PC File Manager) the following utilities work fine with full functionality: dsave, pd, free.
[Back to top]

File permissions
The SMB protocol limitation is the lack of uid, gid and permission information per file. Samba File Manager have to assign those values once for a complete mounted resource (values are inherited from who is smbmount running).
[Back to top]

File names
Incompatibility between DOS and OS-9 file names is a real problem. The PC file name may have up to 255 characters ("Long File Names" feature is available from Windows 95, before maximum file name length was 12 characters only). OS-9 allows for as many as 28 characters in a file name. However, Samba servers can supply the special short (i.e. 12 characters length) file name for clients those cannot handle the new long one. So, if a DOS file name follows OS-9 length for it, you will see it as it is, otherwise it becomes a bit special (with '~' near the end).

Samba file names are case insentinive. Therefore Samba File Manager follows OS-9 agreement to make the directory names uppercase.

DOS file names can contain characters that are not legal in RBF files. Samba File Manager implements its own file name parsing procedure, so it can handle DOS names successfully, but some standard OS-9 utilities like dir, rename use kernel's _os_prsnam() call directly and will fail on such file names. So, try to avoid such characters for files you plan to use with Samba File Manager.
Besides can emerge problems when DOS file name contains characters from the second half of the ASCII table (codes > 0x7F).
[Back to top]

File locking
DOS and OS-9 have a different file locking mechanism. At this moment Samba File Manager supports Exclusive Lock, when opening files with S_ISHARE bit set in access mode field (non-sharable files).

Also I$SetStt/SS_Lock call is supported with the following limitations:

  • This call only can be used to lock/unlock any portion of the file. Read or write of zero bytes (as for Microware's RBF) to unlock is not implemented.
  • If a read/write/lock request is issued for a part of a file that is already locked out, Samba File Manager returns immediately with the error code E$Lock. You cannot use I$SetStt/SS_Ticks to set the delay as RBF does. This occurs because of locking is implemented by the server, not by the client. Possible workaround is to repeat locked request every small period of time (0.5 sec, for example) to retrieve latest locking information from the server, but in this case the network traffic will be increased by far. This also can be done either inside the file manager, or directly by an user application.
  • Locking mechanism is implemented on a File basis.
  • To ensure better OS-9 compatibility, there is no way to gain file lock using only read or write system calls, although Windows NT based Samba servers permit shared locks, when a record is locked out only for writing (other processes may read locked record as usual).
[Back to top]

File buffering
Samba File Manager doesn't perform file buffering inside itself at all. Instead, it supports large blocks transfer (up to 50 Kb) for user's calls (read and write). You can see this behaviour using standard copy utility with -b option set to 50K, for example.
[Back to top]

File descriptors
DOS file system doesn't have a special file descriptor's storage per file as OS-9 does. Instead, information about a file is stored in a directory entry directly. Samba File Manager have to emulate OS-9 file descriptors (FD's) for all files on mounted volume to make standard utilities happy.

Directories on Samba volumes are always null-sized. When a directory is opened for reading, the value 4096 is used instead. However, dir listing still display the value 0. Due to this behaviour, alternate dir utilities (like one written by K.Schmitt, available from os9archive) may work in a wrong way.

Also, the SMB protocol doesn't include such concept as a "current working directory". All requests, which the client dispatches to the server, should include a complete file name (from root level). Thus, it is the file manager's duty to support a special data chunk for all OS-9 processes (but out of the OS-9 process descriptor) to permit them to save information about the current directory using emulated FD (see above).
[Back to top]

File times
OS-9 support for file times is a bit poor. It saves the file modification time on one minute basis, and the file creation time is only the date. On the other hand, Samba server software supports file creation time only from Windows'95 and higher versions. In this case, Samba File Manager try to translate file times as exactly as possible depending on the server software. The additional trouble is Samba server doesn't have correct date/time for its root directory (i.e. physical root, disk C: on FAT filesystem for example). Currently there is no workaround for this problem.

Also it's impossible to change date/time for directories at all. These values are set only once when directory was created.
[Back to top]

Memory usage and possible limitations
Due to necessity to emulate OS-9 like file descriptors as mentioned above, Samba File Manager allocates special chunk of memory (directory cache) for this purposes at startup. The size of this memory depends of emulating FD's count (320 by default, may be changed using special smbmount utility option), with 64 bytes for each directory cache entry.

Because remote file system doesn't have a right directory entry for each file, Samba File Manager needs to emulate it for each readdir() call. This memory is allocated once on each opendir() operation and occupies 128 (also changeable with smbmount utility) directory entries (the maximum count of files in a directory cannot exceed this limit).

Additional memory (about 8 Kbytes) is allocated also at startup for special Samba transfer process's purposes.

Directories can be opened only for reading (you cannot write to a directory at all).

I$GetStat/SS_FDInf call has no global scope as for Microware's RBF. The FD sector address is valid only for directory path opened at this moment.

Because of Samba server's behaviour the directory information may be updated with some delays. The Samba File Manager doesn't use any flushing to prevent increasing network traffic and overloading Samba servers.

If nothing has been received from a client for a while, the Samba server will assume that the client is no longer running and disconnect the client after configurable amount of time which is about one hour. You must unmount and again the resource again by hand from the client's side. Also, when you have opened files on a server, it never will disconnect you. Version II (from edition #201) uses a special keep alive timer to prevent the server to drop the connection in this situation.

smbmount utility doesn't check files opened on Samba volume when unmounting. Be sure, that all used files are closed, otherwise it may crash the entire system.
[Back to top]

Version II of OS-9 Samba File Manager allows multiple asynchronous input/output requests to be sent to the server at one time. Typical servers like Windows 95/98 support 2 simultaneous requests, advanced servers like Windows NT - up to 50 requests.

At the same time, there is some unpleasant limitation at use of this feature. Client cannot use large block transfers (see above) and multiplexing at one time. So, if you want just to transfer some large files from/to server, Version I of OS-9 Samba File Manager will be the best choice. On the other hand, if your applications use mounted disk as a general purpose storage (open/close/read/write a lot of files simultaneously), Version II will supply the best productivity.
[Back to top]

Version II of OS-9 Samba File Manager includes simple print client. Due to Windows printing implementation the mounted printer device is not an real SCF device from the OS-9 side of view. There are not line-by-line printing features, character substitutions and so on. Windows printing system just spools all client output into special "printer" file, and when the client ends its job (i.e. closes the file descriptor), the server begins to print.

Another limitation is that server doesn't take care about client output at all. All client data are going directly to the physical printer. So it is the client duty to implement so-called "driver" functions to support different printer models, as well as various tasks like printing text or image, and so on. In a few words, the Samba file manager gives only "transport" service to transfer user data from an OS-9 machine to the printer in Samba network.

All print jobs supplied with this simple print client are named "OS-9 Print Job" when viewing print jobs list (either local from Windows control panel, or remotely using smbjobs script from OS-9 side).

The user can also assign the proper name to the print job from the user side. Instead of opening the standard device (its name depends on how it was mounted, for example /lpt), you just should add your print job name as an additional path component:

// Use default print job name...
  error = _os_open("/lpt", S_IWRITE, &fd);

// and assign your own
  error = _os_open("/lpt/Your job name", S_IWRITE, &fd);
The small example is available in the distribution archive (see smbspool script).
[Back to top]

Windows Server 2003 notes
From the edition #230 the OS-9 Samba File Manager fully supports the SMB packet signing. If you have the older version, please make the following steps to achieve Windows Server 2003 compatibility.

By default, a Microsoft Windows Server 2003 requires signature of SMB packets (at least, a Windows Server 2003 working as domain controller). To make the OS-9 Samba File Manager work with it, you should disable signatures on the server side.

So, you should look for the following security option: Microsoft network server: Digitally sign commnunications (always) and set it to Disabled, instead of Enabled. This security option modifies the following registry value:

Key: HKLM\SYSTEM\CCS\Service\lanmanserver\parameters\
Value: RequireSecuritySignature
Content: 0 to disable, 1 to enable
If you don't want to reboot after that change, you can stop the srv.sys driver and services that depend on it using the following command:
C:\>net stop srv
Then, you can restart it, as well as the services that depend on it (in particular, netlogon).
C:\>net start srv

[Back to top]

Quick Reconnect
Quick Reconnect feature is used to make a fast and smart reconnect to the server without to lose all user's open files and even locking information. From the command line the function is called with the new smbmount utility option -R=mode. The argument mode controls how the File Manager should perform the command. The value 1 means that the user want to restore all previously open files, and the value 0 forces to skip this process, if the user want to reopen its files manually.

Internally, the user level code can use this feature calling well known I$SetStt/SS_Skip function. For example, in C language:

    u_int32     count = 10;
    char        *buffer;
    error_code  result;

    /* The application opens the file */
    _os_open("/pc/file.ext", S_IREAD, &fd);

    /* Try to read */
    result = _os_read(fd, buffer, &count);
        /* May be, we lose the connection to the server, try to reconnect */
        int32  mode = 1; /* we need restore all open files */
        _os_ss_skip(fd, mode);

        /* and maybe try to read again */
Note:  this feature is incompatible with multiplexing function, so it's disabled in this version.
[Back to top]