Merge bk://cifs.bkbits.net/linux-2.5cifs

into stevef95.austin.ibm.com:/usr/src/bk/linux-2.5cifs

fs/cifs/README

@@ -166,8 +166,28 @@ A partial list of the supported mount options follows:
 		mount.	
   domain	Set the SMB/CIFS workgroup name prepended to the
 		username during CIFS session establishment
-  uid           If CIFS Unix extensions are not supported by the server
-                this overrides the default uid for inodes.
+  uid		If CIFS Unix extensions are not supported by the server
+		this overrides the default uid for inodes. For mounts to
+		servers which do support the CIFS Unix extensions, such
+		as a properly configured Samba server, the server provides
+		the uid, gid and mode.  For servers which do not support
+		the Unix extensions, the default uid (and gid) returned on
+		lookup of existing files is the uid (gid) of the person
+		who executed the mount (root, except when mount.cifs
+		is configured setuid for user mounts) unless the "uid=" 
+		(gid) mount option is specified.  For the uid (gid) of newly
+		created files and directories, ie files created since 
+		the last mount of the server share, the expected uid 
+		(gid) is cached as as long as the inode remains in 
+		memory on the client.   Also note that permission
+		checks (authorization checks) on accesses to a file occur
+		at the server, but there are cases in which an administrator
+		may want to restrict at the client as well.  For those
+		servers which do not report a uid/gid owner
+		(such as Windows), permissions can also be checked at the
+		client, and a crude form of client side permission checking 
+		can be enabled by specifying file_mode and dir_mode on 
+		the client
   gid		If CIFS Unix extensions are not supported by the server
 		this overrides the default gid for inodes.
   file_mode     If CIFS Unix extensions are not supported by the server