Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Bill Stoddard" <bill@wstoddard.com>
To: "APR Development List" <dev@apr.apache.org>
Subject: RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write   on
 Windows
Date: Fri, 25 Oct 2002 14:48:11 -0400
Message-ID: <JHEPKCEMGPKFFDHHDDKDEENCFNAA.bill@wstoddard.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <5.1.0.14.2.20021025125554.02c1a4d0@pop3.rowe-clan.net>
Importance: Normal

> At 12:52 PM 10/25/2002, Bill Stoddard wrote:
> >The point of my comment was that this is irrelevant for what I
> am interested
> >in talking about.
> >
> >But since we are on the topic... APR_XTHREAD implies the file needs to be
> >opened for overlapped i/o.  Files opened for overlapped i/o don't HAVE OS
> >maintained file pointers. I assume (correct me if I am wrong) that
> >APR_APPEND has the same semantic meaning as Unix O_APPEND.  If that
> >assumption is correct, then passing in
> APR_XTHREAD|APR_FILE_APPEND on an apr_file_open is not correct
> and should be flagged as an error at file open
> >time.  My inclination is to make the check at file_open time
> rather than in
> >this code.
>
> Nope.  APR_XTHREAD files must be readable, writeable and totally
> compatible with APR_APPEND.

That's not possible assuming APR_APPEND has the same semantic meaning as
Unix O_APPEND.

> It's a couple of extra LOC, please add
> them or post the final patch for me to massage.  These files have APR
> maintained file pointers for compatibility with the API.

Yes, if the file is opened with APR_BUFFERED, then APR maintains it's own
file pointers. My patch is not touching the APR_BUFFERED path.

Bill