From dev-return-10790-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Dec 17 18:58:42 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 61212 invoked from network); 17 Dec 2003 18:58:42 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 17 Dec 2003 18:58:42 -0000 Received: (qmail 96689 invoked by uid 500); 17 Dec 2003 18:58:33 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 96534 invoked by uid 500); 17 Dec 2003 18:58:32 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 96521 invoked from network); 17 Dec 2003 18:58:32 -0000 Date: Wed, 17 Dec 2003 13:58:11 -0500 (EST) From: Cliff Woolley X-X-Sender: jcw5q@cobra.cs.Virginia.EDU To: Brad Nicholes cc: dev@apr.apache.org Subject: Re: File buckets and downloadng files larger than 4gig... In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Wed, 17 Dec 2003, Brad Nicholes wrote: > before setting the content-length header. The problem is that there > appears to be only one bucket and the length of that bucket is > (actual_filesize - 4gig) for any file greater than 4gig. Weird, but I can believe it. > Where should the dividing up of the whole file into smaller buckets > happen? Right now it's supposed to be happening in the handler. I've always hated that. I think it'd be much cooler if this could be handled inside the buckets code. But I don't know right off where the right place to do that would be. Can't do it in apr_bucket_file_create() by having it create multiple buckets and chaining them, because the bucket creation operation is semantically restricted to creating only /one/ bucket, and violating that would cause all kinds of macro ops to be broken. Can't do it in file_bucket_read() by having a single file bucket contain the large file and just pretend it had either only 4GB of data or by having e->length == -1 (size unknown), because that would cause apr_brigade_length() to do the wrong thing [return an incorrect brigade length or have to actually read the file in to memory (or mmap it), respectively, both of which are Badness]. I'll try to think of an alternative, but suggestions are welcome. --Cliff