This is version 0.10 of ncpfs, a free NetWare client filesystem for
Linux.

The main change for this release is that the directory kernel-1.3 is
removed. Guess why? ncpfs is in the standard kernel since 1.3.53. But
please note that ncpfs does NOT work with 1.3.53. I sent a fix to
Linus, so it should work fine with 1.3.54, or 1.3.55.

I would like to invite you to write documentation. As those whose
native tongue is English might have noticed, my C is better than my
English. So I doubt that everything in the man/ subdirectory is
written very well. Please feel free to send me any comments about
that.


INSTALLATION

The installation of ncpfs depends on the kernel version you are
using. For kernel 1.2, you should simply type 'make' and look at
what's in the bin/ directory after that. Please be sure that your
kernel resides in /usr/src/linux, because the file kernel-1.2/sock.c
has to refer directly to it.

If you use Kernel 1.3, please be sure that you use at least 1.3.54 (or
1.3.55, if 1.3.54 makes ncp connections hang). ncpfs does NOT work
with any earlier 1.3.x kernel, especially not with 1.3.53, although it
has a fs/ncpfs/ subdirectory.

If you use Kernel 1.3.54 or later, you might have to recompile your
kernel. With these kernels, the kernel part of ncpfs is already
included in the main source tree. If you want to use ncpfs, you should
say 'y' to 'make config' when you are asked for IPX, and again when it
asks for ncpfs. After you have rebooted with the new kernel, 'cat
/proc/filesystems' should show you a line saying that the kernel knows
ncpfs.

With Kernel 1.3.54 or later you also have to modify the Makefile in the
directory you found this README in. Please see the Makefile for the
necessary modifications. Then typing 'make' should work with no
problem.


USING NCPFS

Please note that your IPX system has to be configured correctly. If
you want to take the 'Plug-and-Play' route, you can simply say
'ipx_configure --auto_interface=on --auto_primary=on'. If ncpmount
does not work immediately, you should wait for about 1 minute and try
again. In that period, an IPX packet should have passed by and your
network interface should have configured itself automatically.

If all that does not work and you want to do the configuration by
hand, note that there has to be a route to the internal network of
your server. Please see the file util/start_ipx for an example.

I use tools written by Greg Page, Caldera. I hope I did not do too
much harm to their business. For your convenience I included the file
ipx.tar made available by Caldera.

My main source of information is a book written in german by Manfred
Hill and Ralf Zessin, "Netzwerkprogrammierung in C", IWT Verlag GmbH,
1995, ISBN 3-88322-491-X. It contains quite a lot of typographical and
other errors, but I find it very valuable as an introduction to NCP
programming. If you know about the concepts and possibilities of NCP,
Ralph Brown's interrupt list becomes much more readable. It's much
easier to find undocumented information if you know what to look for!

For the curious: the files ncplib.[ch] are a library that makes it
possible to send NCP requests to the server over a mounted
directory. I use it to keep the encryption stuff out of the kernel by
logging in from user space. Look at the file ncptest.c for other
possible uses. I use ncptest to check my assumptions about the widely
undocumented NetWare Core Protocol.  Maybe this is the beginning of a
free NetWare API for Linux! I would be happy to receive your comments
on this.


LIMITATIONS (compare these with smbfs :-)

The limitations ncpfs has are the natural limitations of the NCP
protocol, which was designed with MS-DOS based PCs in mind. The first
limitation is the lack of uid, gid and permission information per
file. You have to assign those values once for a complete mounted
directory.

The second limitation is just as annoying as the first: You cannot
re-export a ncp-mounted directory by nfs. It is not possible because
the NFS protocol defines access to files through unique file handles,
which can be mapped to the device and inode numbers in unix NFS
servers. NCP does not have unique numbers per file, you only have the
path name. I implemented a caching scheme for inode numbers, which
gives unique inode numbers for every open file in the system. This is
just sufficient for local use of the files, because you can tell when
an inode number can be discarded. With NFS the situation is
different. You can never know when the client will access the file-id
you offered, so you would have to cache the inode numbers
indefinitely long. I think this should not be done in kernel mode, as
it would require an unlimited amount of RAM.