Date: Fri, 10 Dec 2010 18:21:54 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: 1.7.7: upper limit to df reported available size?
Message-ID: <20101210172154.GI25347@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <33F9E32CDB0917428758DD583E747CC80DC11C1C@OntExch3.ontario.int.ec.gc.ca> <20101210165930.GA5210@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20101210165930.GA5210@calimero.vinschen.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Dec 10 17:59, Corinna Vinschen wrote:
> On Dec 10 11:20, Elford,Andrew [Ontario] wrote:
> > $ df -T /cygdrive/f/file
> > Filesystem    Type   1K-blocks      Used Available Use% Mounted on
> > C:            ntfs    83886076  31717608  52168468  38% /cygdrive/c
> > F:            ntfs   11717703676  72036296 -5534201804   -  /cygdrive/f
> > L:            ntfs   6143999996 883063196 5260936800  15% /cygdrive/l
> [...]
> Hmm.  OTOH, seeing the size of your FS, I'm also wondering if we should
> make the algorithm a bit more foolproof for the future by manipulating
> the value of f_frsize if the TotalAllocationUnits returned by Windows
> is > sizeof (fsblkcnt_t).

No, scratch that.  It wouldn't work well.  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).


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple