Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 88898 invoked from network); 23 Sep 2010 15:38:05 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 23 Sep 2010 15:38:05 -0000 Received: (qmail 46468 invoked by uid 500); 23 Sep 2010 15:38:05 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 46162 invoked by uid 500); 23 Sep 2010 15:38:03 -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 46154 invoked by uid 99); 23 Sep 2010 15:38:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Sep 2010 15:38:03 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com designates 209.85.161.52 as permitted sender) Received: from [209.85.161.52] (HELO mail-fx0-f52.google.com) (209.85.161.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Sep 2010 15:37:56 +0000 Received: by fxm17 with SMTP id 17so1598171fxm.11 for ; Thu, 23 Sep 2010 08:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=dLH5awMZRjmEGHhdeNF/3YoVbz8h4+y/ewZEJalhzhY=; b=MeEK2BcTZowzXrylU8IQYGHxY+JeHieKCkZbr9SIiufVs5BT8CclxvcXXCxSVkwmYs qAMpilAcJslA7UPZYu8IVuKzkm3xcJEQFSArnL1FuZ8ktkm0c4uDBkylDw7b2dE0Aqh7 prUBataijH0SGNNHUMW0/emhc79SJbq/4aWd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oVcP8BsPEvko+2bo2NoReYi4AlzjrV+0G7oPJhHybNKuug3hRQJD+6j5Z5/MJuaOYB /Pk2kiPY8IqzmEhAuSJui/PM7K4hIZBvu74+wDLnhL457f7iRv1xJsrqfJBMbkxOeZb+ yqSAH2OMJ6T8zZFNP/mVDrNXPT8RZ72qtpejI= MIME-Version: 1.0 Received: by 10.223.107.80 with SMTP id a16mr2224700fap.30.1285256254722; Thu, 23 Sep 2010 08:37:34 -0700 (PDT) Received: by 10.223.111.141 with HTTP; Thu, 23 Sep 2010 08:37:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Sep 2010 17:37:34 +0200 Message-ID: Subject: Re: question about how write_header works From: Randall Leeds To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 On Thu, Sep 23, 2010 at 15:44, Paul Davis wrote: > As to the header2 or header1 problem, if header2 appears to be > corrupted or is otherwise discarded, the header search just continues > through the file looking for the next valid header. In this case that > would mean that newData2 would not be considered valid data and > ignored. It's worth noting that headers appear on specific boundaries (I don't remember offhand, but might be 4K.) Non-header data is broken across this boundary with a 0 byte so that you can even store a CouchDB file inside another CouchDB database and the code cannot mistakenly find an incorrect header.