Re: filexfer-07

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Richard Whalen wrote:
> > -----Original Message-----
> > From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost]On
> > Behalf Of Joseph Galbraith
> > Sent: Friday, April 01, 2005 4:59 PM
> > To: der Mouse
> > Cc: ietf-ssh%NetBSD.org@localhost
> > Subject: Re: filexfer-07
> >
> >
> > > 7.1.1.3, describing SSH_FXF_ACCESS_READ_LOCK: s/gaurantee/guarantee/
> > > (twice).  Also, it's not clear whether "the exclusive reader" means
> > > with respect to other sftp clients or with respect to all other OS
> > > activity; and, an exclusive read lock is a very peculiar 
> >
> > thing, and not
> >
> > > at all what a "read lock" normally does.
> >
> > All right; I renamed it to SSH_FXF_ACCESS_EXCLUSIVE_READ,
> > and changed it to say:
> >
> >   The server MUST guarantee that no other handle has been
> >   opened with ACE4_READ_DATA access, and that no other
> >   handle will be opened with ACE4_READ_DATA access until
> >   the client closes the handle.  (This MUST apply both
> >   to other clients and to other processes on the server.)
> >
> >   If there is a conflicting lock the server MUST return
> >   SSH_FX_LOCK_CONFLICT.  If the server cannot make the locking
> >   guarantee, it MUST return SSH_FX_OP_UNSUPPORTED.
> >
> >   Other handles MAY be opened for ACE4_WRITE_DATA or any other
> >   access, as long as it does not include ACE4_READ_DATA.
> >
> > Is this better?
>
>
> I think that the lock described is still pretty unusual for a file.

It reflects the windows file sharing model.

In windows, you say I'm willing to let others READ, write or
delete (or any combination thereof) this file while I'm
accessing it.

Hence, EXCLUSIVE_READ is I'm willing to let other WRITE or
DELETE this file.

> When accessing a file the usual methods of locking are:
> None - I don't care if there is other current access, I'll
> take my chances if something modifies it while I'm
> writing/reading it.

This is no locking bit set.

> Read - I don't want anyone to modify the file (or its
> attributes) while I'm reading it.  I don't care about
> other readers.

This is EXCLUSIVE_WRITE set (and probably DELETE_LOCK)

> Write - I don't want anyone else to be accessing the
> file while I access it for write. I don't want to
> risk others getting a corrupt file while I'm changing it.

This is EXCLUSIVE_WRITE|EXCLUSIVE_READ (and possibly
DELETE_LOCK)

The only potential problem is that you may not be able
to support EXCLUSIVE_READ set by itself-- in which case
you'd have to return UNSUPPORTED for that lock request.

And unfortunately, that limitation can't be expressed
in the "supported2" extension.

I'll add a note that clients that use the locking
bits might need to watch out for this.

(I expect most clients will want the default
unix behavior of no bits set.)

Do you have any other suggestions of how to accomadate both
models?

Thanks,

Joseph