apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@xbc.nu>
Subject Re: cvs commit: apr/test testfileinfo.c
Date Tue, 11 Feb 2003 22:01:48 GMT
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   <brane@xbc.nu>   http://www.xbc.nu/brane/

View raw message