On Mon, Aug 23, 1999 at 10:59:10PM -0400, Chuck Robey wrote:
> > Dunno about that.. if you're using advisory locking, you know to say
> > "lock the file, then read the data, do your calculation, write it out,
> > and unlock". This manditory locking sounds like an invitation for
> > disaster. "I don't need to pay attention to the details because
> > the kernel will take care of it for me."
> >
> > Actually, I don't really understand the paradigm. Two processes need
> > to safely update a file, so one of them aquires a mandatory lock, and
> > the other.. uh.. just blocks trying to open the file? How does it
> > know it's not the first one?
>
> It means that if user A puts data in (and follows locking procedure
> correctly) then he doesn't have to worry that user B might not be
> following correct locking procedure, because user B is mandatorily
> forced to follow the procedure. There isn't any added sloppiness, just
> a guarantee that if one user locks a file, no other rogues can get into
> it while the lock exists.
Bleah.. I can't count the number of times I've seen idiotic code like:
open file
read data
close file
open file for write
write data
close file
Mandatory locking of the type above doesn't force such a thing to work.
Now that I've read the rest of the thread, I see that the meaning may
be that certain files are marked such that they can't be opened
without locking. That seems extremely dangerous, given all the time
that such a thing hasn't been around.. who knows how many scripts and
programs will now be vulnerable to hanging forever.. can I lock my
maildrop? My web pages? My print spool?
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
