> 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.
> Please don't assume that
> someone won't mix the APR_APPEND bit with either APR_XTHREAD
> or APR_SENDFILE_ENABLE (both of which must toggle APR_XTHREAD
> so TransmitFile has an overlapped file.)
>
> It seems you only need APR_FLOCK_WRITE in this context, we
> really shouldn't lock users that are attempting to tail -f the file.
Good point. Not sure if LockFileEx will give us what we need though.
>
> I suspect that's you ignoring rv != APR_SUCCESS...
Nope. I've futzed with this code quite a bit and at one point, I was
checking return codes and setting breakpoints in the debugger on the error
paths and those breakpoints never hit. If I move the SetFilePointer() call
before the call to apr_file_lock(), then I do not see the hang. The only
code example in MSDN shows the SetFilePointer being called before
LockFile(), which is not correct IMO (ie consider what happens when process
1 swaps out right after calling SetFilePointer() and process 2 writes a
bunch of bytes to the open file).
Bill
