On Friday, April 01, 2005 05:24:44 PM -0500 Richard Whalen <Whalenr%process.com@localhost> 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. 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. 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. 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.
I agree, the locking semantics the document describes are pretty bizarre. In general, a read lock excludes writers, while a write lock excludes both readers and other writers.
Also, it is worth noting that the current text, especially with the requirement that locks MUST apply to other processes on the server, basically requires the use of operating-system-provided mandatory file locking. This is problematic because on some systems, mandatory locking is rarely used, if it is available at all, and the sftp server may not be in a position to influence whether mandatory locking is used for a particular file.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA