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. 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.