Subject: RE: COMMIT clarifications

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 22 Oct 2001 09:39:30 -0700

Peter Åstrand wrote:
> I have som questions regardarding the COMMIT operation. 

> 1) Is it legal to do COMMIT on a filehandle representing an file open for 
> read only? The CITI impl. seems to allow this. It also seems to work to 
> allow COMMIT on a FH from LOOKUP. Legal?

I would say so.  I certainly don't do any checks on the open status of
the file represented by the filehandle.  If that were required,
COMMIT would have a stateid parameter, or a lockowner, or even a
client-id.

The filehandle doesn't represent the file open, the stateid does.

COMMIT makes sure that any uncommitted writed gets to stable
storage and if there are none, that is OK. 

Right now, my implementation doesn't even check the validity of
the filehandle on COMMIT (we always do writes to table storage).
I think I should fix that but what file types are valid?
I would say NF4REG or NFS4NAMEDATTR.  I guess NFS4ERR_ISDIR is
the right error for a directory but what about orher types.

> 2) offset limits: What should the server return in case offset is 
> ouf-of-bounds (eg. much greater than the size of the object)?

If I do async writes, the some other client truncates the file,
I don't think I should get an error when I do my COMMIT.

> 3) Same goes for count: What to return if offset+count is greater than the 
> size? NFS4_OK?

Yes.  But if offset+count >= 2**64, NFS4ERR_INVAL.

---

From: Peter Åstrand <[email-masked]>
Date: Tue, 23 Oct 2001 12:16:00 +0200 (CEST)

> The filehandle doesn't represent the file open, the stateid does.

Thanks. 

> the right error for a directory but what about orher types.

What about returning NFS4ERR_INVAL for other objects? Or, maybe a more
symmetric solution would be to add NFS4ERR_ISLNK, NFS4ERR_ISBLK etc...

-- 
Peter Åstrand                Telephone: +46-13-29 08 61
Cendio Systems               E-mail: [email-masked]
Teknikringen 3
583 30 Linköping

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 23 Oct 2001 23:58:55 -0500

> symmetric solution would be to add NFS4ERR_ISLNK, NFS4ERR_ISBLK etc...

Given that this type of error indicates an error in the client
implementation,
I believe that NFS4ERR_INVAL is sufficient.

Spencer