Joe Orton wrote:
>On Tue, Feb 11, 2003 at 06:41:36PM +0100, Branko Äibej wrote:
>
>
>>Joe Orton wrote:
>>
>>
>>
>>>On Sat, Feb 08, 2003 at 02:21:28AM +0100, Branko Äibej wrote:
>>>
>>>
>>>>I expect that change would avoid the problem, yes. (In fact, in
>>>>Subversion, I did an explicit fluxh befode calling apr_file_info_get,
>>>>for this very reason.) I was sort of hoping someone had a better idea
>>>>for a fix, though; forcing a flush before every stat seems to me to
>>>>defeat the whole purpose of buffering.
>>>>
>>>>
>>>>
>>>>
>>>I'm confused by that - buffering means "some writes are deferred", so a
>>>direct consequence of that is that the st_size returned by a stat on the
>>>file may not equal the number of bytes passed to apr_file_write, right?
>>>If you want stat().st_size to always equal the number of bytes passed to
>>>apr_file_write, then it sounds like you don't want to use buffering?
>>>
>>>
>>>
>>>
>>Heh. The OS usually has file buffers, too, and yet stat() always tells
>>you what the size of the file would be if all write()s were committed,
>>not what the size on disk actually is. If apr_file_write has an internal
>>buffer, then apr_file_info_get should obviously be aware of that and
>>adjust the results accordingly, without having to flush the buffers
>>first -- and becoming orders of magnitude less efficient.
>>
>>
>
>Ah, I wondered if that's what you were getting at. That analogy is a
>bit stretched, since if a stat() or fstat() reports st_size = X, you
>will be able to read() X bytes from the file, from any process. If
>apr_file_info_get lies about the st_size, the size returned is only
>valid for access to the file via that particular apr_file_t *, which
>would seem to break the principle of least surprise, at least.
>
That's a good point, but...
>What if the app passes it off to another library, or something?
>
You can't do that (portably) without some other APR magic anyway. And
even ignoring that, the situation is no worse than the frintf + fork
situatiion, for example -- if you pass buffered APR files to non-APR
code, then you have to flush them first.
My point is that apr_file_seek _does_ take buffering into account, so
apr_file_info_get should, too.
>Anyway, this is presumably what you mean: flushing still seems best to
>me, but I don't really care, I just want my builds to stop failing
>everywhere! ;)
>
You did commit the flush fix, didn't you? (/me looks...) Oh, you didn't!
>--- filestat.c 7 Jan 2003 00:52:53 -0000 1.64
>+++ filestat.c 11 Feb 2003 18:19:12 -0000
>@@ -135,6 +135,8 @@
> finfo->pool = thefile->pool;
> finfo->fname = thefile->fname;
> fill_out_finfo(finfo, &info, wanted);
>+ if (thefile->buffered)
>+ finfo->size += thefile->bufpos;
> return (wanted & ~finfo->valid) ? APR_INCOMPLETE : APR_SUCCESS;
> }
> else {
>
>
Hmm, does this patch actually work? I suspect the calculation would be
slightly more involved -- after all, the buffer might not extend past
the hard end-of-file at all.
--
Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
