From dev-return-4582-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Jun 10 23:58:14 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 85532 invoked from network); 10 Jun 2009 23:58:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Jun 2009 23:58:14 -0000 Received: (qmail 4121 invoked by uid 500); 10 Jun 2009 23:58:26 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 4033 invoked by uid 500); 10 Jun 2009 23:58:25 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 4023 invoked by uid 99); 10 Jun 2009 23:58:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jun 2009 23:58:25 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of skippy.hammond@gmail.com designates 209.85.200.171 as permitted sender) Received: from [209.85.200.171] (HELO wf-out-1314.google.com) (209.85.200.171) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jun 2009 23:58:16 +0000 Received: by wf-out-1314.google.com with SMTP id 28so373090wfa.29 for ; Wed, 10 Jun 2009 16:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=N596nw6KNntBSVFw4ghpH+mpkRplupHVYguDbaWRATA=; b=OjNOJVCUNn9pF2m1kENF5EMfKN71pkVUr2nATIN4ImJOHsGBmpg17DS1Obm9F+OV0p QCYKzmAytkHUg7+QLqog3PZM8zD8bxjWJRY/6uboO2Gf+eDa5sCLA71kbmT6N10Txr8B gOrNUwkgIaDZlcF9sxGHnkbp4hk5GHLVKfqk8= 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=fppyH7i1ojzOHDAHiviBjjXGMV9u8gn+MKT4TRcIejUVN4OgTmLPyoeVkUyDrcTMZv 4ScSgswcoY8gd/2SoTsYht6KpI80AQbROh6/g7w7jzNyCl1SbZR0iGhL2FSebY6shg/k IUGI1/vfZcOlwSrJ+pr1AS7dChUIrtRVdCkwg= Received: by 10.142.154.9 with SMTP id b9mr834486wfe.154.1244678276103; Wed, 10 Jun 2009 16:57:56 -0700 (PDT) Received: from ?192.168.0.12? (202.168.100.57.dynamic.rev.eftel.com [202.168.100.57]) by mx.google.com with ESMTPS id 28sm1636559wfg.5.2009.06.10.16.57.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 16:57:55 -0700 (PDT) Message-ID: <4A304825.60103@gmail.com> Date: Thu, 11 Jun 2009 09:56:21 +1000 From: Mark Hammond Reply-To: mhammond@skippinet.com.au User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: dev@couchdb.apache.org Subject: Re: Windows support References: <64883581-F4C3-4C01-842E-CFF1DFF26656@apache.org> In-Reply-To: <64883581-F4C3-4C01-842E-CFF1DFF26656@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 4/06/2009 3:27 AM, Damien Katz wrote: > I was once again reminded we need to add proper Windows support for > CouchDB when Mark Hammond provided a very nice patch to provide a > windows version of a couchdb unix script. (Thanks Mark!) Thanks! Sorry I was a bit slow to see this thread. > But we also have some broken tests. Other than the issue Mark's patch > fixes, I think it's only compaction that's still broken. compaction and deletion are broken. I've opened a bug on the delete problem at https://issues.apache.org/jira/browse/COUCHDB-326, as alisdair seemed to think that couch could have a simple change made to allow 'delete' to work without changing how the files are opened. > I think the > cleanest way to fix that is to change the erlang VM to open db files > using flags to give them unix like semantics. I've learnt something about Windows file-systems today :) My experiments show that when using FILE_SHARE_DELETE: * A file can be deleted while it is in use - but another file of that name can not be created until the handles are closed. * A file can however be renamed while it is in use, thereby allowing the original name to be re-opened. If we consider the 'delete' case, then FILE_SHARE_DELETE may still end up with a 'race' if an attempt to delete the DB is quickly followed by a request to create it - the delete should succeed, but the create will not. If we consider the 'compact' case, I *suspect* that couch will need to rely on the ability to rename and replace rather than a simple delete - so that might work fine. I'll have a bit of a dig around in the erlang sources and see what I find, but of you have any other thoughts or pointers in the meantime, please let me know. Cheers, Mark