Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of skippy.hammond@gmail.com
 designates 209.85.210.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=o9CwX3kOYZf40nTSkvjwJhog90jYZWSZ2s8O9Bd4nE+z+EoMel5p0bqKsu5PIz/ABc
         wXXAhTRm5IuF+QFqcTRr76Lde1mOht1DauQ0x649Z1yXlb8STHLxUt58zXeHv3y/iHdf
         ArrbDEU4KNKePcWjwR9mBQ9NM4xB6mGU3yQ9U=
Message-ID: <4AEE3260.3040600@gmail.com>
Date: Mon, 02 Nov 2009 12:14:08 +1100
From: Mark Hammond <skippy.hammond@gmail.com>
Reply-To: mhammond@skippinet.com.au
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
MIME-Version: 1.0
To: dev@couchdb.apache.org
Subject: Re: Anyone using couchdb on windows for real?? I'm considering.
References: <e55356640910310755g6ef2cea1ja6f8de89ef36884@mail.gmail.com>
In-Reply-To: <e55356640910310755g6ef2cea1ja6f8de89ef36884@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 1/11/2009 1:55 AM, Juhani R�nkimies wrote:
> I searched windows related issues from jira and I'm worried about two of them:
>
> https://issues.apache.org/jira/browse/COUCHDB-86 ( compaction doesn't work )
> https://issues.apache.org/jira/browse/COUCHDB-222 ( fsync problem )
>
> The compaction issue resolution is "Don't Fix", and it refers to
> discussion on issue 67 (unicode chars in db names) for a solution. I
> need the compaction from the start and I got it to work with the
> attached dirty fix. That'll do for now, but I'd like to understand how
> 67 will solve the problem.

This is all fairly vague, but IIUC the general idea was that issue 67 
would provide a level of indirection between the DB name and the actual 
file name, primarily to support database names which are invalid 
file-system names.  Then this general support could possibly be 
leveraged so that whenever a database needs to be rolled over, instead 
of trying to replace it directly on the file-system (which fails on 
Windows), we just update the "pointer" to use a new name, serving all 
new requests from that db and deleting the old database once everything 
has caught up and released the old DB.

Also, my mailer isn't showing the "dirty fix" attachment - could you 
please resend it (either to me personally or via the list)?

> The fsync issue worries me because I don't exactly undestand it's
> implications. It'd be great if someone would elaborate.

I'm not 100% sure, but I *think* the issue was that file:sync() on 
erlang under windows used to be a noop - eg, see:

http://www.erlang.org/pipermail/erlang-questions/2007-March/025485.html

But following the lead from that post, I see in R13B01 the source for 
that impl is now:

efile_fsync(errInfo, fd)
Efile_error* errInfo;		/* Where to return error codes. */
int fd;				/* File descriptor for file to sync. */
{
     if (!FlushFileBuffers((HANDLE) fd)) {
	return check_error(-1, errInfo);
...

Which looks to me like it is no longer of concern.

Cheers,

Mark