> > > At 09:27 AM 10/25/2002, Bill Stoddard wrote:
> > > >The only problem with this patch [...]
> > > >
> > > >--- readwrite.c 19 Sep 2002 12:20:20 -0000 1.1.1.1
> > > >+++ readwrite.c 25 Oct 2002 13:44:53 -0000
> > > >- if (thefile->pOverlapped && !thefile->pipe) {
> > > >- thefile->pOverlapped->Offset =
> (DWORD)thefile->filePtr;
> > > >- thefile->pOverlapped->OffsetHigh =
> > > (DWORD)(thefile->filePtr >>
> > > >32);
> > > >- }
> > > >- else if (!thefile->pipe && thefile->append) {
> > > >+ if (thefile->append && !thefile->pipe) {
> > > >+ int rc;
> > > >+ rc = apr_file_lock(thefile, APR_FLOCK_EXCLUSIVE);
> > > >+ if (rc != APR_SUCCESS) {
> > > >+ rc = APR_SUCCESS;
> > > >+ }
> > > > SetFilePointer(thefile->filehand, 0, NULL, FILE_END);
> > >
> > > You can't just drop the Overlapped test. there is NO CURRENT POSITION
> > > if you have opened a file for overlapped I/O.
> >
> > I know. Overlapped is not used when writing to the access log.
>
> But you are writing code for APR here, not Apache. You can't gaurantee
> that nobody will try to use Overlapped with APPEND.
>
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.
Bill, passing in APR_FLOCK_SHARED fixed the problem. (hitting my forehead
and sounding like a Homer).
Bill
