Subject: [nfsv4] [PATCH] Detail what happens at the EOF for a file with no holes

From: Thomas Haynes <[email-masked]>
Date: Fri, 23 May 2014 10:08:06 -0700

From: Tom Haynes <[email-masked]>

I'm very fine with the addition of NFS4ERR_NXIO.

I'm not so pumped on the remaining text - it seems that if we
set EOF, we already capture the intent Anna wanted.

Comments?

Suggested-by: Anna Schumaker <[email-masked]>
Signed-off-by: Tom Haynes <[email-masked]>
---
 nfsv42_middle_op_seek.xml | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/nfsv42_middle_op_seek.xml b/nfsv42_middle_op_seek.xml
index c0ca1e2..5de2f1c 100644
--- a/nfsv42_middle_op_seek.xml
+++ b/nfsv42_middle_op_seek.xml
@@ -25,7 +25,15 @@
       sa_what in the file. If the server can not find a corresponding
       sa_what, then the status will still be NFS4_OK, but sr_eof
       would be TRUE.  If the server can find the sa_what, then the
-      sr_offset is the start of that content.
+      sr_offset is the start of that content.  If the sa_offset is
+      beyond the end of the file, then SEEK MUST return NFS4ERR_NXIO.
+    </t>
+
+    <t>
+      All files MUST have a virtual hole at the end of the file. I.e.,
+      if a filesystem does not support sparse files, then a compound
+      with {SEEK 0 NFS4_CONTENT_HOLE;} would return a result of
+      {SEEK 1 X;} where 'X' was the size of the file.
     </t>
 
     <t>
-- 
1.9.0