Import ncpfs 0.17

README

@@ -78,6 +78,8 @@ Ales Dyrak has written lwared, which was the initial start for ncpfs.
 
 Alan Cox has found some bugs I would probably never have found.
 
+Look at the file Changes for others.
+
 
 LIMITATIONS (compare these with smbfs :-)
 
@@ -87,27 +89,7 @@ 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.
-
-Those who looked at the kernel code a bit closer will have found out
-that the last section is a little white lie. As I found out after the
-first version of ncpfs, NetWare does indeed offer something like inode
-numbers, although are only unique per volume. So one way to make ncpfs
-re-exportable by nfs is to allocate a superblock per volume and show
-the inode numbers to the user. I was just too lazy to do this
-yet. Maybe once we will force Novell to make NetWare NFS
-affordable... ;-)
+You will not be able to access servers that require packet
+signatures. This seems to be one of Novell's bigger secrets :-(.
 
 Have fun with ncpfs!