apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: [PATCH] Support APR_APPEND (O_APPEND) with apr_file_write on Windows
Date Fri, 25 Oct 2002 17:18:57 GMT

> 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


Mime
View raw message