Justin Gombos wrote:
<> I'm bothered by the whole lockfile concept, because it seems that
<> procmail is being forced to do a job that is better handled by the
<> filesystem and OS. It's the rightful job of the OS to control access
<> to resources (like files). A user should be able to declare to the OS
<> that a particular file only have one producer at a time, and if
<> another process or application attempts to write to such a file when
<> it's already open for write by another, the OS should block it. This
<> logic should not be left to the application.
Not clear on what you're saying ...
In fact, invoking a lock on a file IS declaring to the OS that there
may be only one process writing to the file. Are you suggesting that
an OS should provide a facility to make this declaration at the time
a file is created? 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.
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.
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.
Reto
--
R A Lichtensteiger rali(_at_)tifosi(_dot_)com
Ringwraiths killed: 4. V. good.
Met up with Hobbits. Walked forty miles. Skinned a squirrel and ate it.
Still not King.
____________________________________________________________
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