X-Spam-Check-By: sourceware.org
Message-ID: <440EE246.3030909@byu.net>
Date: Wed, 08 Mar 2006 06:55:18 -0700
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: partition size incorrectly reported
References: <1ACB95D81B24969895E72CC1 AT red-2> <20060308125503 DOT GR3184 AT calimero DOT vinschen DOT de> <440ED903 DOT 7000605 AT byu DOT net> <20060308132346 DOT GS3184 AT calimero DOT vinschen DOT de> <20060308133729 DOT GT3184 AT calimero DOT vinschen DOT de>
In-Reply-To: <20060308133729.GT3184@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 3/8/2006 6:37 AM:
>> Maybe Cygwin can do something about that by never returning more
>> available than total blocks.  Would that be helpful/desirable/correct,
>> or sahould we just keep it as it is now?

I'm still thinking about the best approach here.  Also, right now it seems
that coreutils is preferring statfs over statvfs, even though statvfs is
the standardized interface (it is a known issue recently raised on the
upstream mailing list).

> 
> Hang on... I'm just looking into the output of statvfs on a drive which
> has a 1Meg quota for the current user in place.  The values in the
> statvfs structure correspond to the return values of GetDiskFreeSpaceEx
> like this:
> 
>   f_blocks == TotalNumberOfBytes     (corresponds to quota)
>   f_bfree  == TotalNumberOfFreeBytes (does NOT correspond to quota)
>   f_bavail == FreeBytesAvailable     (corresponds to quota)
> 
> The values returned for the quota challanged drive:
> 
> f_bsize  : 4096
> f_blocks : 256		(256 * f_bsize) == 1 Meg
> f_bfree  : 1339399	(real free blocks of the drive)
> f_bavail : 0		(blocks free for user under quota lore)
> 
> Per standard, f_bavail shows the number of free blocks available to
> non-superuser.  However, df seems to use the f_bfree value, which is,
> per standard, the number of total blocks free on the drive.  I'm
> wondering if df shouldn't rather use f_bavail and f_blocks instead of
> f_bfree and f_blocks?!?
> 
> What Cygwin could do is to write the FreeBytesAvailable value also into
> f_bfree, but I'm wincing at this idea since it would (unnecessarily?)
> reduce the information available in the structure.  I'm not actually
> convinced this would be a good idea.

Is it worth adding additional fields to struct statvfs to avoid loss of
information (of course, then those fields are not portable, because they
are not standardized)?  What does Linux do in the presence of user quotas?

- --
Life is short - so eat dessert first!

Eric Blake             ebb9 AT byu DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEDuJF84KuGfSFAYARAtcoAKCV6+2i/6fj3a/TgIGPO2DzOM3VzwCgnrZQ
12N1RlGezfUMnBCdpes+3xE=
=dSCP
-----END PGP SIGNATURE-----

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