Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-Id: <5.1.0.14.2.20021025125554.02c1a4d0@pop3.rowe-clan.net>
Date: Fri, 25 Oct 2002 12:59:17 -0500
To: "Bill Stoddard" <bill@wstoddard.com>
From: "William A. Rowe, Jr." <wrowe@apache.org>
Subject: RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write
  on Windows
Cc: "APR Development List" <dev@apr.apache.org>
In-Reply-To: <JHEPKCEMGPKFFDHHDDKDMEMMFNAA.bill@wstoddard.com>
References: <Pine.LNX.4.21.0210251319510.14059-100000@shell.ntrnet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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.  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.  APR_XTHREAD
and APR_SENDFILE_ENABLE must remain semantically equivalent
to a usual file.  They simply might consume more overhead, or less,
depending on what the application is.

>Bill, passing in APR_FLOCK_SHARED fixed the problem. (hitting my forehead
>and sounding like a Homer).

You can't flock SHARED... that denies everyone (including yourself)
write access to the file.  Please review the FileLockEx docs.