> 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.
That's not possible assuming APR_APPEND has the same semantic meaning as Unix O_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. Yes, if the file is opened with APR_BUFFERED, then APR maintains it's own file pointers. My patch is not touching the APR_BUFFERED path. Bill
