>> >The reason for locking the file is to mutex the file pointer. A file > opened for > >overlapped i/o does not have a file pointer. > >I'm not aware of any restrictions but I've not tested this patch and > I think the > >results will be less than predictable. For instance, we lock the file, call > >WriteFile and get back IO_PENDING, then we unlock the file. Maybe the i/o > >occured by the time we released the lock. Or maybe not. The > function is broken, > >with or without this patch when used for writing to files opened for > overlapped > >i/o. I'm not sure the best way to fix it (or even if we should fix > it). I'm -0 > >on this patch. > > Bill, now you aren't reading :-) > Please take a moment and review apr_file_seek()... > > The code never sets the file pointer through the win32 API. There is > no bug. As long as we hold the file lock, the size won't change. The > WriteFile uses the filePtr value for the overlapped value. > > apr_file_seek, for XTHREAD/overlapped files, simply updates filePtr based > on your request, relative to the old filePtr value :-) So we still want the > file lock, to hold the length of the file constant, until our file > write completes. > > Hope that clears things up. > > Bill
Ahh, there's much magic in apr_file_seek. Okay, +1 on the patch. It will work. Bill
