IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: filexfer-07





On Monday, April 04, 2005 05:25:58 PM -0600 Joseph Galbraith <galb-list%vandyke.com@localhost> wrote:

Jeffrey Hutzelman wrote:


On Monday, April 04, 2005 06:54:18 PM -0400 Bill Sommerfeld
<sommerfeld%sun.com@localhost> wrote:

On Mon, 2005-04-04 at 18:39, Jeffrey Hutzelman wrote:

On most Unix systems, an SFTP server can guarantee to its client that I
can't get a lock on a file, but it can't guarantee that I won't just
write  to the file without bothering to get a lock.


unix systems which implement mandatory file locking (typically
SVR4-derived) typically do so on a file-by-file basis -- one particular
combination of file mode bits was recast to mean that  normally-advisory
byte-range locks become mandatory, blocking attempts to do I/O in
conflict with the lock.  this prevents you from mixing advisory and
mandatory locks on the same file.


Correct.  It also means that changing the locking mode requires changing
the file mode bits, which normally can be done only by the file's owner
or by a superuser.

But the server can tell what locking mode is available, and
respond correctly?  Though it may have to advertise both modes
and responde with UNSUPPORTED for some files.

This requires platform-specific knowledge, but yes, the server can generally tell what sort of locking is available. If sftp is to support both types of locking, then the spec should be written such that a server can claim to support advisory locking even when locks it sets are actually mandatory. Put another way, an advisory lock should not require the server to prohibit other processes from accessing the file, but it should not preclude it from doing so, either.

-- Jeff



Home | Main Index | Thread Index | Old Index