apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: cvs commit: apr/test testfileinfo.c
Date Tue, 11 Feb 2003 18:33:55 GMT
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.  What if
the app passes it off to another library, or something?

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! ;) 

--- 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 {



Mime
View raw message