[Evolution-hackers] Making file-locking configurable at
runtime? (UG#4795)
Not Zed
notzed@ximian.com
Wed, 16 Feb 2005 08:26:44 +0800
--=-KsYENbYSBmpr/ETOJ0Bp
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
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.
--=-KsYENbYSBmpr/ETOJ0Bp
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.5.5">
</HEAD>
<BODY>
On Tue, 2005-02-15 at 18:54 +0200, Enver ALTIN wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi,</FONT>
<FONT COLOR="#000000">We have a somewhat complex intranet consisting of several XDMCP/NFS</FONT>
<FONT COLOR="#000000">servers and we're running applications with NFS mounted home folders</FONT>
<FONT COLOR="#000000">(probably other folders too).</FONT>
<FONT COLOR="#000000">NFS servers are running in vserver context and are using somewhat</FONT>
<FONT COLOR="#000000">modified kernels (some security and vserver patches added) so I've been</FONT>
<FONT COLOR="#000000">told that we're not able to get rpc.statd work properly. Thus, neither</FONT>
<FONT COLOR="#000000">fcntl() nor flock() works for us.</FONT>
<FONT COLOR="#000000">For that reason, I have re-packaged evolution with file-locking disabled</FONT>
<FONT COLOR="#000000">and dot-locking enabled. While we're at it, we have been wondering if it</FONT>
<FONT COLOR="#000000">could be possible to make it configurable at runtime.</FONT>
</PRE>
</BLOCKQUOTE>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">What I think is, to convert compile time things a lookup to GConf and do</FONT>
<FONT COLOR="#000000">the preferred way of locking. If I come up with a patch implementing</FONT>
<FONT COLOR="#000000">this, would that ever get committed?</FONT>
</PRE>
</BLOCKQUOTE>
An environmental variable would probably suffice. Is there any reason that wouldn't be good enough?<BR>
<BR>
camel definitely can't use gconf, although an api could be added to set the locking mode, and that called from code that can.<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
--=-KsYENbYSBmpr/ETOJ0Bp--