upper limit to df reported available size?

Eric Blake eblake@redhat.com
Mon Dec 13 21:28:00 GMT 2010

On 12/10/2010 06:51 PM, Jay K wrote:
>  >  I guess what we really need
>  > is to redefine fsblkcnt_t to become a 64 bit type. Oh well, this
>  > requires another backward compatibility hack, just like back when we
>  > switched to 64 bit off_t (Cygwin 1.5). Let's do it at the same time as
>  > we change sigset_t and time_t to 64-bits(with knock-on effects to
>  > struct stat, among others). In other words,all good changes, but certainly
>  > something that will take a lot ofplanning to pull off in one go.
> Can you fix the jmp_buf size then too maybe?
> It is blown up by a factor of 4.
> http://sourceware.org/ml/cygwin/2009-01/msg00863.html
> I realize it has less/no value to fixing.
> But I'm not sure how changing the others won't require *everything*
> (just about) to be recompiled anyway. Maybe you rename functions somehow?

It's a matter of linker magic.  For example, when stat() was changed
from 32-bit to 64-bit sizes, cygwin1.dll was set up with two entry
points, stat() and stat64(), but the dll export table only has one entry
point stat().  Old apps that were compiled when there was only a 32-bit
entry point continue to call stat(), but now that the dll export table
exposes only stat pointing to stat64(), all recompilations automatically
pick up the new stat size.  There's also some #defines required in the
headers to allow compilation of cygwin itself to support both function
calls, while only exposing the new sizes to newly compiled apps.

When (if? since someone has to do it) fsblkcnt_t is resized, you won't
be required to recompile, but you won't benefit from the fixed sizes
unless you recompile.  And coreutils (including df) would obviously be
one of the first apps to recompile with the new sizes, as a good
testcase that we got the resizing done correctly.

Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20101213/6fd9bb40/attachment.sig>

More information about the Cygwin mailing list