Re: svn commit: r592305 - /apr/apr/trunk/test/testlfs.c

[Lucian Adrian Grijincu <lu...@gmail.com>]

On Nov 6, 2007 8:34 AM,  <wr...@apache.org> wrote:
> Author: wrowe
> Date: Mon Nov  5 22:34:18 2007
> New Revision: 592305
>
> URL: http://svn.apache.org/viewvc?rev=592305&view=rev
> Log:
> On some (bogus) platforms we can only discover csize-by-name.
> Ask for it, either way.
>

Would you be so kind as to point out which platforms?

> Modified:
>     apr/apr/trunk/test/testlfs.c
>
> Modified: apr/apr/trunk/test/testlfs.c
> URL: http://svn.apache.org/viewvc/apr/apr/trunk/test/testlfs.c?rev=592305&r1=592304&r2=592305&view=diff
> ==============================================================================
> --- apr/apr/trunk/test/testlfs.c (original)
> +++ apr/apr/trunk/test/testlfs.c Mon Nov  5 22:34:18 2007
> @@ -66,6 +66,8 @@
>
>      if (rv == APR_SUCCESS) {
>          rv = apr_file_info_get(&testsize, APR_FINFO_CSIZE, f);
> +        if (rv == APR_INCOMPLETE)
> +            rv = apr_stat(&testsize, TESTFN, APR_FINFO_CSIZE, p);
>      }

shouldn't this be inside APR code for apr_file_info_get?
if it failed using today's code, it should run code from apr_stat to
try and determine the file size, shouldn't it?


>
>      /* give up if we can't determine the allocation size of the file,
>
>
>



-- 
Lucian

Re: svn commit: r592305 - /apr/apr/trunk/test/testlfs.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Lucian Adrian Grijincu wrote:
> On Nov 6, 2007 8:34 AM,  <wr...@apache.org> wrote:
>> Author: wrowe
>> Date: Mon Nov  5 22:34:18 2007
>> New Revision: 592305
>>
>> URL: http://svn.apache.org/viewvc?rev=592305&view=rev
>> Log:
>> On some (bogus) platforms we can only discover csize-by-name.
>> Ask for it, either way.
>>
> 
> Would you be so kind as to point out which platforms?

In this case now, Win32.  Right now, OS2 and Netware appear to entirely
implement csize in all cases, I'm unsure if they implement enough glue
to handle sparse files right now.  I trust that Netware can create sparse
files given the right glue, unsure of OS2.  What's especially irritating
is that the converse would never be true; we can always open a handle in
a filestat.c handler for apr_stat, if that's the path to learning various
file info bits :-/

On the platforms I'd tested, our 1MB test-file allocation seems to be
doing a nice job of dodging our 8GB bigfile creation.

>>      if (rv == APR_SUCCESS) {
>>          rv = apr_file_info_get(&testsize, APR_FINFO_CSIZE, f);
>> +        if (rv == APR_INCOMPLETE)
>> +            rv = apr_stat(&testsize, TESTFN, APR_FINFO_CSIZE, p);
>>      }
> 
> shouldn't this be inside APR code for apr_file_info_get?
> if it failed using today's code, it should run code from apr_stat to
> try and determine the file size, shouldn't it?

Uhm - you can't run stat without the filename.  You can't presume that
apr_file_info_get knows a filename (e.g. fd/handle's can arrive as stdio
channels, and in some cases the named resource no longer exists, and even
when it exists, that it still points to the same resource).

And we don't have an API until Vista/2008 (Longhorn) to see the file
allocation/compression, while sparse files date back to 2000 and the
compressed files date to NT4 (GetCompressedSize dates only to 2000).

If you can point out a compression/allocation by-handle API that is
available stock (not the Win32 File-ID addin), it's much appreciated.
I hadn't begun to delve into what the underlying NTDLL might tell us.

Bill