From dev-return-8359-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Oct 29 18:04:00 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 78098 invoked by uid 500); 29 Oct 2002 18:03:59 -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 78085 invoked from network); 29 Oct 2002 18:03:58 -0000 From: "Bill Stoddard" To: "APR Development List" Subject: RE: cvs commit: apr/file_io/win32 filedup.c open.c readwrite.c Date: Tue, 29 Oct 2002 12:58:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.2.20021029114458.0261bb10@pop3.rowe-clan.net> Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >> >The reason for locking the file is to mutex the file pointer. A file > opened for > >overlapped i/o does not have a file pointer. > >I'm not aware of any restrictions but I've not tested this patch and > I think the > >results will be less than predictable. For instance, we lock the file, call > >WriteFile and get back IO_PENDING, then we unlock the file. Maybe the i/o > >occured by the time we released the lock. Or maybe not. The > function is broken, > >with or without this patch when used for writing to files opened for > overlapped > >i/o. I'm not sure the best way to fix it (or even if we should fix > it). I'm -0 > >on this patch. > > Bill, now you aren't reading :-) > Please take a moment and review apr_file_seek()... > > The code never sets the file pointer through the win32 API. There is > no bug. As long as we hold the file lock, the size won't change. The > WriteFile uses the filePtr value for the overlapped value. > > apr_file_seek, for XTHREAD/overlapped files, simply updates filePtr based > on your request, relative to the old filePtr value :-) So we still want the > file lock, to hold the length of the file constant, until our file > write completes. > > Hope that clears things up. > > Bill Ahh, there's much magic in apr_file_seek. Okay, +1 on the patch. It will work. Bill