given a delegation type received on open, set buffering flags accordingly.
however, provide -o nocoherence mount options that will enable read/write
buffering regardless
when we receive a delegation recall, we need to make a downcall
to the kernel and change a buffering/caching policy on this file.
on each open and close we pass an srv_open pointer to the nfsd to
keep in case it receives a cb_recall. we store srv_open in the
delegation state if we got a delegation.
when we didn't create a mount, we don't have a security context to
destroy. in vnetroot creation, initialize session to invalid_handle.
if we fail to mount, then before deleting security context in
nfs41_FinalizeVNetRoot check that session is not invalid_handle.
when nobody is waiting for the upcall. if it was read/write upcall
unlock readwrite mdl. if it was a readdir upcall, unlock readdir
mdl and also free it.
none (or all) functions should be static. making all function non-static.
consistent format of function args (ie each argument on its own line).
adding __notnull for our fcb, fobx, vnetroot, netroot context pointers.
removed some non-implemented function from our redirector functions table.
left some no-op functions that are just required: flush, isvaliddir,
deallocatefcb. not sure about completebufferingstate function.
80char lines corrections
nfs41_np.c:
NPAddConnection3() was overwriting status=WN_BAD_NETNAME on any errors from DeviceIoControl()
nfs41_driver.c:
GetConnectionHandle() was only returning the handle, and throwing away the return value from ZwCreateFile()
map_mount_errors() was missing a mapping from ERROR_BAD_NET_NAME to STATUS_BAD_NETWORK_NAME
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
it complained that mdls had to have a certain (undocumented) flag set.
also, it seemed to imply that in readdir, the locking of pages needed
to be done by the thread creating the mdl. so i moved the locking/unlocking
there.
if the nfs_mount passes us a read-only mount option. then return
access_denied if:
1. requests for open with desired access of write or append,
2. we get a write irp,
3. requests for setattr, setattrex, setacl
4. ignore the delete_on_open flag passed to open
on a mount request, search a list of existing mounts for a given netroot
based on LUID entries (login ids). if an entry is found, then check the
current request rpcsec flavor against existing sessions/mounts. If no
match found, do another upcall for a mount and store a session of this
flavor for this LUID. if no entry found for this LUID, then do a mount
upcall, create a new entry and add it to the list.
windows api frequently sends a query security with a buffer len of 0
to figure out how big of buffer is needed for a security descriptor.
we send a getattr for acl attribute on the 1st irp, then cache the
returned security descriptor in fobx. on the 2nd query, if the buffer
is cached and it's not "stale", we return that buffer.
added 2011 year to the copyright line
added authors info to the license
added UofM license to libtirpc files that we modified
(but i probably missed some)
this function was called before writes and was setting time and size
attributes of the file. we were translating it into a setattr. reads
were also followed by a setattr of timestamp (unnecessarily)
proposes an alternate solution for attempts to set file size without an open sta
teid. instead of acquiring one by sending OPEN, fail the request with ACCESS_DE
NIED
according the MS File System Algorithms documentation for setting FileAllocation
Information and FileEndOfFileInformation [http://msdn.microsoft.com/en-us/librar
y/ff469355%28v=PROT.10%29.aspx]:
"If Open.GrantedAccess does not contain FILE_WRITE_DATA, the operation MUST be f
ailed with STATUS_ACCESS_DENIED"
-removes open_owner_id, access_mask, access_mode from setattr upcall arguments
-moves map_access_2_allowdeny() back to open.c as a static function, since handl
e_setattr() was its only other call site
Deleting client's security context was causing kernel crashes.
During upcall, we remember a pointer to the client's security context,
then on close we delete the security context. Previously we would also
delete the context if the upcall was abandoned.
Apparently, windows will always send a close for the fcb that was used
for the abandoned upcall. Close deletes the context. Then when upcall
was done, it would try to delete the context again (oops).
