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/


Mime
View raw message