Re: filexfer-07

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> I'm not terribly familar with the advisory locking implemenated on
> most unix platforms [...].

> I presume it has basically three levels of locking, none, read (don't
> allow writers) and write (exclusive.)

Right.

> I presume the lock request fails if there is already a violation?

Depends.  With all interfaces I know of, when you request a lock, you
specify (typically by setting or not setting an optional bit) what to
do if the lock requested cannot be acquired immediately, one behaviour
being to sleep until it can be acquired and the other being to return
immediately with a distinctive error.

> What happens when a new access request comes along that violates the
> advisory lock?  Is the original lock holder notified in some fashion?

By "access request" you mean I/O attempt?  Nothing.  That's the
"advisory" bit: the locks have nothing whatever to do with actually
reading or writing the file; all they really affect is other lock
attempts on the file.

> Is it appropraite to lock a open time, or should it be a seperate
> request?

Recent BSD has the O_SHLOCK and O_EXLOCK flags to open(2), which take a
shared or exclusive lock atomically with opening the file.  Since
opening an existing file is not an operation with semantic significance
to anyone else, the atomicity is irrelevant except when the open
actually creates the file.  Similar remarks apply to opening and
locking over sftp, as far as I can see.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B