Re: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795)

[Not Zed <notzed ximian com>]

On Tue, 2005-02-15 at 18:54 +0200, Enver ALTIN wrote:
> Hi,
>
> We have a somewhat complex intranet consisting of several XDMCP/NFS
> servers and we're running applications with NFS mounted home folders
> (probably other folders too).
>
> NFS servers are running in vserver context and are using somewhat
> modified kernels (some security and vserver patches added) so I've been
> told that we're not able to get rpc.statd work properly. Thus, neither
> fcntl() nor flock() works for us.
>
> For that reason, I have re-packaged evolution with file-locking disabled
> and dot-locking enabled. While we're at it, we have been wondering if it
> could be possible to make it configurable at runtime.
Well thats why its configurable at build time, *generally* it is a site issue, and evolution is free software.  Although it is possible to conceive of complex situations in which 2 different locking types were required on different filesystems.
> What I think is, to convert compile time things a lookup to GConf and do
> the preferred way of locking. If I come up with a patch implementing
> this, would that ever get committed?
An environmental variable would probably suffice.  Is there any reason that wouldn't be good enough?

camel definitely can't use gconf, although an api could be added to set the locking mode, and that called from code that can.