X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=Lm3oisCJQXmRzhQGX9YIusp5xZU7wqNNbGH5ocq2bOfTjUTw52PFs
	tTtYlOuRawtVdz7HR84Ld2VxiHwRHU/PpZLIRdIPNOJ6OZYl1VVW8QZePpdP2HPN
	E3tljSeZzi/1pX3mNw17wwe5lLWIqCmOmS6fBjqaeGokSqTrjWp/CM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=tCyKhqxNvuIgIBhBNd25BbzwIg4=; b=cGMbr68/a4fULuXATLhFvkTRPb7M
	4aFSvZ97cLD0pfKXj8OiC1ZpI5SNiZ+xJvCv43tlUldPlBMoukdp8Oh2+KeeLubW
	zDprY3b3zABSUHqgERGGI2Uz/0BdLUzxlB4cdSGHKFez46ouwqyPZdhgdUyAw34w
	fbKRjOPEZR64PwA=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
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
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Thu, 28 Aug 2014 14:31:25 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Why does df fail to stat CIFS shares?
Message-ID: <20140828123125.GS20700@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20140627143626 DOT GA9220 AT F1S712WWS> <20140703094152 DOT GB1803 AT calimero DOT vinschen DOT de> <loom DOT 20140826T110928-929 AT post DOT gmane DOT org> <20140826124557 DOT GB5740 AT calimero DOT vinschen DOT de> <loom DOT 20140827T165747-369 AT post DOT gmane DOT org> <20140827151536 DOT GK20700 AT calimero DOT vinschen DOT de> <20140827153700 DOT GL20700 AT calimero DOT vinschen DOT de> <loom DOT 20140827T181656-215 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="Vsi50HYs5tPfr+1I"
Content-Disposition: inline
In-Reply-To: <loom.20140827T181656-215@post.gmane.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

--Vsi50HYs5tPfr+1I
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 27 16:28, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > -v, please.  What means "obviously" here?  Did you ask Netapp?
>=20
> No, I've tried all combinations of parameters to the open calls to
> absolutely no avail.  I then started to look at what the VolumeInformation
> call is supposed to be doing and decided that this might have a better
> chance of producing a workaround.
>=20
> > > The FileFsFullSizeInformation class is *old*, it has been introduced
> > > with Windows 2000.  Did you test all combinations I asked you for?  C=
an
> > > you provide detailed results?  It might help to find a working combin=
ation.
>=20
> All combinations you listed produced absolutely the same behaviour than
> before: the open suceeds and the VolumeInfo call fails.  I've tried a few
> other combinations that are forbidden according to MSDN and promptly had =
the
> open call fail, so I think I did this correctly...
>=20
> While searching the net I've found some notes saying that the only classes
> confirmed working everywhere didn't include FileFsFullSizeInformation.  T=
rue
> or not, that's what pushed me to rip it out.
>=20
> http://sourceforge.net/p/openxdk/patches/_discuss/thread/4b412944/4ba5/at=
tachment/undocumented.txt
>=20
> > Btw., one other hare-brained idea would be if the Netapp FS has a
> > somewhat different idea of the size of FILE_FS_FULL_SIZE_INFORMATION,
> > maybe due to a misunderstanding in alignment.  What you could try is
> > to make full_fsi a pointer:
> >=20
> >   PFILE_FS_FULL_SIZE_INFORMATION full_fsi =3D
> >   	(PFILE_FS_FULL_SIZE_INFORMATION)
> > 	alloca (2 * sizeof (FILE_FS_FULL_SIZE_INFORMATION));
> >=20
> > and then change all "full_fsi." to "full_fsi->"
>=20
> Tomorrow...
>=20
> > If nothing else works, try this workaround for size:
>=20
> That's essentially what I've done to get it working.  Not that exact patc=
h,
> so I'll try that out tomorrow as well, but that code path should produce
> correct output from df no matter of what FS it finds behind the mount.

I've applied my patch since it certainly doesn't hurt.  At least not
more than those bugs in various filesystems.  It seems the minimal
requirements for filesystems to get MSFT blessing are *very* low :(


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--Vsi50HYs5tPfr+1I
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJT/yEdAAoJEPU2Bp2uRE+gmqYP/1jXP2whSyh5UueUBGtmZNWf
Plusm6Po1zMOBN0w082a9JN7ySAY253f2YZ4CrnefF/nS7n5Yhi2ARentKcw6Z70
3aLwGSQBoKXnlvlNbAgtxzh/PcwUNrwTqGAcuz3VqCkYGhGffokfzdr3brRDOnDx
0sVVHKPzGCZf0CVuPLwVT1nghmvXlYNX+DvUvlXqWfitWTGKSPownse7mvyya3Pu
mT/pRHF9MOuAEaLyvIZeNBHC24PtmoaoJkUS1g+mAkYa7p6hB6KD6t2QbBcog5Fk
4QWCJtJcrTiG43piB6wIAOu4oOJyl6yeR3IPp5pStzYgc+Dlo9lqopapUPYUkOay
k5xuitghNVHWRaly7SaDLtnmRI400uh5ZrSb5EQPE4KbAdWM4ZQ0899L2KEfFWM7
WyMZ2pIGXksOLWdDUQOsGM0YmsIhYhBZ9RwuI9bU4jgM1Q5XNIfSLY1z8VtaUtBh
b/x07zhpMfdqELFX6HVQAOD66ZsQqGKcms3F96YOh/3dPFotgbNsZZd1jjfeif8F
TN21GTKglhpViX0hjm/FDWN8nq3SSVqCHxQhwIsff5ZWcB/9Ei5j0HJpVWhQXw5+
LPxjLhdo0IpO5eeCuaaoDn8SSRFXp7sedIjUY26MfAQJrp0parqZ4b+BtiX5P2t/
jEvsz5mEJKD+80mq/jXL
=1Jwu
-----END PGP SIGNATURE-----

--Vsi50HYs5tPfr+1I--