		The TrueGrid NFS Server
		TECHNICAL ISSUES & ANSWERS

	A Freeware NFS Server for Windows 95/NT

COPYRIGHT (C) BY XYZ SCIENTIFIC APPLICATIONS, INC., 1998
ALL RIGHTS RESERVED.  TrueGrid IS A TRADEMARK OF
XYZ SCIENTIFIC APPLICATIONS, INC.

		XYZ Scientific Applications, Inc.
		1324 Concannon Blvd.
		Livermore, CA  94550

DISCLAIMER OF WARRANTY
----------------------
NO WARRANTIES. THE SOFTWARE PRODUCT IS PROVIDED "AS IS" WITHOUT WARRANTY
OF ANY KIND. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, XYZ
AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY AGAINST
INFRINGEMENT, WITH REGARD TO THE SOFTWARE PRODUCT. THIS LIMITED
WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHERS, WHICH
VARY FROM STATE/JURISDICTION TO STATE/JURISDICTION.

CUSTOMER REMEDIES. XYZ'S ENTIRE LIABILITY AND YOUR EXCLUSIVE REMEDY
SHALL NOT EXCEED THE PRICE PAID FOR THE SOFTWARE PRODUCT.

NO LIABILITY FOR DAMAGES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE
LAW, IN NO EVENT SHALL XYZ OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES
WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS
PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR ANY
OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE
THIS XYZ PRODUCT, EVEN IF XYZ HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.

=====================================================================
Here we discuss some of the technical issues arising from the fact
that PC file systems are not completely compatible with UNIX file
systems.

IBM WORKSTATIONS. **** Warning **** IBM workstations rely on non-standard
	behaviour.  For example, IBM workstations expect the size of
	directories to depend on the number of entries in the directory
	and the lengths of their names.  PC's treat directories as having
	no length.  So, we report a size of 8192 bytes.  This is enough
	for most directories.  But "cp -r" can crash on the IBM if 8192
	is not big enough for the contents of the directory.  This problem
	is not easily solved because the UNIX size of a directory can
	be computed only after reading the entire directory, and that
	would be horribly inefficient.

PERMISSIONS.  UNIX permissions include read, write, execute permissions
	for user, group and other.  This does not fit that well with
	Windows.  It can be made to fit reasonably well with NT, but
	not with Windows 95.  So, by default, we use the same
	permissions for user group and other.  This can be changed
	for all files, but not for individual files using our "umask="
	option (see the exports file).

	We show all files as having execute permission.  If we just
	assigned execute permission to Windows types of executables,
	then we would be unable to execute certain UNIX files in the
	UNIX environment.  So, we show all files and directories as
	having execute permission.

	We also show all files to have read permission.  Windows allows
	you to remove write permission, but not just read permission.

USER & GROUP.  We make no attempt to map Windows users and groups to
	UNIX-style users and groups.  We show all files and directories
	as being owned by root user and root group.  This can be changed
	with the "uid=" option and "gid=" option in the exports file
	(see the exports file).  But the change is global.

INODES.  This is a sticky issue.  UNIX file systems all use the
	"inode" as an identifier of a file.  Each file and directory
	has a unique "inode" associated with it.  There is no equivalent
	for the PC.  Unfortunately, UNIX systems may not function properly
	unless "inodes" are used.  So, we randomly assign inodes to files
	and directories. These inodes remain the same so long as the
	NFS program is running.  However, they all can change when the
	program is restarted.  Consequently, whenever the server is
	restarted, we report all file handles as "Stale".  This means
	that UNIX systems accessing these files will report errors
	(usually "Stale NFS Handle" messages).  If you see this, then
	"cd" to the top of the exported file system and come back down
	again.  The UNIX system will refresh itself and see the new
	handles and inodes.

LINKS: HARD AND SYMBOLIC.  We do not support hard links or symbolic
	links.  Attempting to link one file to another will result
	in a permission error.  Most UNIX workstations do not allow
	for the possibility that hard links will fail.  Therefore,
	they may not even print a message.  Hard links are related
	to inodes and do not fit well in the PC world.

CASE-SENSITIIVTY.  Windows file names are case-insensitive.  This
	is a small problem for UNIX.  However, the NFS server simply
	compares names using the case-insensitive string compare function.
	So, "ls FileName", "ls fileName", and "ls filename" all report
	the same information on the UNIX side.  This can be dangerous.
	For example, if you have a UNIX directory with "Makefile" and
	"makefile" in it, then copy of the entire directory to the NFS
	mounted PC file system will result in the destruction of one
	of the two files (the last one copied overwrites the first).
	A similar problem occurs with files whose names end in ".".
	Windows does not provide for a distinction between "file"
	and "file.".  So be careful.  We preserve the case wherever
	possible so that at least recursive copies back and forth
	will preserve the case.

MEMORY USEAGE.  The NFS server is fairly efficient, except for the
	fact that we must save "inodes".  Consequently, the entire
	directory system must be stored, along with the "inodes".
	Memory:
		     FILE:	Local Name and a NULL + 12 bytes
		DIRECTORY:	Local Name and a NULL + 28 bytes
	Additional workspace amounting to no more than 250KB can be
	used.  The memory is allocated dynamically as needed.  And
	the memory is recovered when files or directories are removed.
	
FILE CACHE.  We cache files.  It is not possible to have a reasonably
	efficient NFS server that does not cache files.  The time
	required to open and close a file makes it impractical to
	open the file every time an I/O operation is performed (the
	I/O request buffer is limited in size to about 8KB because
	of RPC limits).  Doing so causes horrible latencies and
	thrashing.  So, we open files and leave them open.  Up to
	32 files are kept open.  When that number is exceeded, then
	the last-accessed file is closed and we open the new one.
	Or, if the attributes of a file are changed (permissions,
	size, owner), then we close the file.  File caches also
	automatically close after one minute, provided there is some
	NFS event to trigger the server to check (even showmount will
	cause this).  This can create a problem.  You cannot destroy
	a file that is open (except from the UNIX side).  If this
	happens, then use "touch" on the UNIX side or use "showmount -e"
	on the PC side to close the cache.  Alternatively, we close the
	file when the user reads the last section of the file.
	So UNIX "tail" will cause the cache to expire.  None of
	these problems is particularly likely to affect you, but
	you should be aware of the potential for difficulty.

WRITE BUFFER SIZE: We suggest that when you mount these file systems
	you use a write-buffer size of 1024 bytes.  Some machines
	will work better with larger buffers, but 1024 works reasonably
	well for all machines.  The buffers must be set on the client
	side.  For example, on the UNIX machine
		mount -o wsize=1024 host:/c /usr/pc
	will mount the remote file system "/c" from the machine whose
	host name is "host" on "/usr/pc" and use a write-buffer size
	of 1024 bytes.  The DEC Alpha is particularly sensitive to
	this setting.  With this option, nearly theoretical transfer
	speeds occur for the DEC.  Without it, retransmits slow the
	system to fast modem speed!

ATTRIBUTE CACHEING: Most UNIX clients cache attributes so that they
	make fewer calls to the server.  This can create problems.
	For example, SUN workstations do not re-read directories
	until they find that the modification time on the directory
	has changed.  But PC's do not change the modification time
	of a directory when entries are added or removed.  You can
	force the SUN not to cache attributes, but we chose to report
	the current time for the modification time of a directory.
	Most clients never use "getattr" since the NFS "lookup"
	function returns everything they need.  So most never see
	this quirk.  However, SGI machines call both (why, who knows).
	So, the SGI shows a continually changing time for directories.
	But, there seem to be no serious consequences.  Without this,
	the SUN clients may not see files added or files removed until
	the cache has expired.  The latter situation is far worse than
	the former.
