At 1:21 AM +0900 8/24/99, Daniel C. Sobral wrote:
Well, I'd say advisory lock does the job if the software is written
right, and if the software is not written right, mandatory locking
won't help.
Let's give an example. You right a program using mandatory locking
making access to a file. I write an "incorrect" program accessing
that file.
I garantee you that the file is going to be screwed up, because I
intend to write random output to it as soon as I get access to it.
After all, if I'm incorrect, I'm allowed to do anything.
There's a difference between a program which has a locking-oversight
or race-condition, and a program you write to deliberately destroy
data.
The thing about well-intentioned but incorrect locking code is that
it will appear to work fine, until it trips over the one code path
where it forgets to lock some file that it should have locked. And
even then, the code will "work" just fine, until multiple processes
are accessing that file at the same time.
I think it is appropriate for an operating system to provide an option
such that *it* (the system) will enforce the locking, and not have to
trust that all code-paths in all programs will do the right thing
WRT advisory locking.
(I also think the implementation needs to be thought out carefully, to
make sure it doesn't become a way for a malicious user to implement
denial-of-service attacks...)
---
Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu
Senior Systems Programmer or dro...@rpi.edu
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
