Technical notes |
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.
|
|
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.
|
|
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:
|
|
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).
|
|
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.
|
|
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.
|
|
Multiplexing
|
|
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.
|
|
Printing
|
|
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 enableIf 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 srvThen, 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);
if(result)
/* 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] |