80 lines
3.4 KiB
Plaintext
80 lines
3.4 KiB
Plaintext
This is version 0.2 of ncpfs, a free NetWare client for Linux. For me
|
|
it works with 1.3.32
|
|
|
|
I know that this piece of software is VERY incomplete, I have to
|
|
apologize for that. But I thought I should make it publically
|
|
available, because I have tried to ask several people about the legal
|
|
status of the code. I did not get very satisfying answers. So I publish
|
|
ncpfs to open it for criticism. If nobody complains, I will go on
|
|
working.
|
|
|
|
To install ncpfs, just type 'make', 'insmod ncpfs.o' and then
|
|
'ncpmount server mount-point'. Please note that your IPX system has to
|
|
be configured correctly. There has to be a route to the internal
|
|
network of your server. Please see the file 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!
|
|
|
|
|
|
MAILING LIST
|
|
|
|
There is a mailing list for discussing lwared and ncpfs. Here's the
|
|
message I received after subscribing:
|
|
|
|
---
|
|
Thank you for your subscription to the list "linware".
|
|
|
|
Topics for the list:
|
|
- discussing LinWare server, its features, installation problems and bugs
|
|
- using IPX protocol under Linux
|
|
- IPX routing and router daemons under Linux
|
|
|
|
Send your list postings to address: "linware@sh.cvut.cz"
|
|
Send your list control commands to address: "listserv@sh.cvut.cz"
|
|
---
|
|
|
|
You can subscribe to this list by sending a message with a line
|
|
'add your_name@your_host linware' to listserv@sh.cvut.cz .
|
|
|
|
|
|
NCPLIB
|
|
|
|
For the curious: the file ncplib.c is usable from user space as well.
|
|
Look at the file ncptest.c for a possible use. 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.
|