* R A Lichtensteiger <rali(_at_)tifosi(_dot_)com> [2004-08-05 16:33]:
In fact, invoking a lock on a file IS declaring to the OS that there
may be only one process writing to the file.
I thought the OS could not care less if there is a lockfile present,
and if a malicious or ill-configured process decides to write to a
file that already has a producer, the OS won't object. Isn't that
correct?
Even if the OS knows about lockfiles and prevents it, it's silly to
open and write a new file solely for the purpose of setting a flag,
when the file at issue could contain a flag, which only requires a
file read.
Are you suggesting that an OS should provide a facility to make this
declaration at the time a file is created?
Yes; or anytime for that matter. A file header should have a settable
parameter indicating whether writes must be exclusive.
It's possible to do that, but I don't know of an OS that does so.
Doesn't mean they don't exist, of course.
Someone mentioned OpenVMS.. but I'm not familiar w/ that OS. Is it
anything like VAX?
As for lockfiles vs. kernel locks [ie fctl()], that results from
history; early NFS had terribe support for in kernel locking. Even
when the admin for the file server ran the NFS locking daemons,
which wasn't required by the spec, the lock requests could go
astray. Thus, using a file on disk as a semaphore was the best
safeguard for file integrity in that environment.
And I don't have a real deep understanding of kernel locks, so it
could be that kernel locks are poorly implemented. But I don't see
why it should be such a problem.
If you know your procmail will never be used over a networked file
system, you can compile procmail w/o the dotlocking feature and rely
on the kernel locking schemas.
That sounds like a good idea. I didn't realize procmail had kernel
locking ability. I might look into that.
I'm still at a loss for why kernel locks are ineffective over network
shares. If the file is protected at the OS level, a redundant write
coming over the network still requires OS interaction, and should
still be blocked.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail