file can be opened with a delete_on_close flag set. this file can be
opened again as long as opens specify "file_share_delete" access.
after receiving the cleanup irp, the handle enters "delete-pending"
state. opens in this state must fail with status_delete_pending.
file query for standard_info.delete_pending now should return true.
calling setattr with disposition=1 puts the file in "delete-pending"
state.
calling setattr with dispositon=0 will clear delete_on_close only
if file is in "delete-pending" state. otherwise, setattr is ignored.
removing notepad opens file as a directory ifdef
for volume query notepad supplies insufficient buffer space but
doesn't like buffer_too_small error code. it seems to be fine
with partial buffer filled and buffer_overflow error.
entry->filename points to something the app address space. if app was
started and the ctrl-ed c, then when nfsd picks up the upcall it should
check if the pointer is still valid
windows can send a create irp with dispostion representing creation
of the file and specify DesiredAccess of 0.
we were treating no data access as lookup but in this case, we still
need to create a file. so send an open with a read access and
request no delegation to be returned.
in comparing server identities, in previous commit we removed
comparison of the returned clientids.
however, running against the emc server, we ran into issues of data
servers retuning the same server major, minor, and scope identities
but different clientids. we then decided that it's the same data
server.
cb_handle was declared as HANDLE * instead of just HANDLE and then
used as HANDLE. However, ran into issues with WaitOnSingleObject(cb_handle)
never returning.
adding -o timeout=value (in sec) mount option to override a default
timeout value for the upcalls for non-io upcalls. Default timeout is
at least the lease_time seconds of an established mount or 20secs.
read/write upcall also take into account number of bytes for the request
and 100MB/s network speed and 100MB/s disk speed
when we are doing non-pnfs and writing to a netapp filer, even though we
write UNSTABLE it returns us FILE_SYNC4. since we were doing unstable
writes we were not sending getattrs, and since the data servers we returning
stable commits we didn't send commit. in doing so, we never update our
attribute cache and had a wrong file size.
client was previously only sending RECLAIM_COMPLETE during grace period. the spec mandates that RECLAIM_COMPLETE be sent before any non-reclaim locking operations, regardless of grace period. when recovery code detects a NFS4ERR_NO_GRACE error, send RECLAIM_COMPLETE immediately before attempting any out-of-grace recovery
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
CB_GETATTR specifies the delegation by filehandle, but deleg_fh_cmp() was comparing superblock and fileid. renamed deleg_fh_cmp() to deleg_file_cmp(), and created new deleg_fh_cmp() to compare actual filehandles
call to nfs41_attr_cache_lookup() was not setting flags in info.attrmask, so the change and size attributes were not being encoded in the CB_GETATTR response
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
