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=uQmUijQgTezi4sRZUv8FhMc0ROSA8k71Qvdjz/BT2B8AkGvUuMogx
	XpVnWGMG50bEKo35rtfifHje3GG8MjWQH/E204WVGYtaekKxZYKgHtirbLUIVPmY
	aVs2Iw5BHGoZ8qH1zrmDPYP6XhphBQ8IpDFq1IZfjryYkDd/gVRLnI=
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=VzCJPH9ADOefqi1OGUzpWR6dbsA=; b=mpeaLOoah7pQyv+HEW53oo2SY7WA
	fkAY3zjLJY2kec0IAGItbEI91pI0GFlLOcmGDmyuxfAgtvdG6dI9Tx7t95O+MbIX
	hKvyr9y0FZW07Ca1WDyOXL1N6CDXqPnOPmjYo6ZK3GMd2X0aTiScxOUTQ11WWsCM
	P4zhv3TiFKA8MmI=
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.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Wed, 21 Oct 2015 13:07:34 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: fstat st_size on open files on Parallels filesystem is wrong
Message-ID:	<20151021110734.GO5319@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<21333 DOT 25325 DOT 11106 DOT 958642 AT compute01 DOT cs DOT columbia DOT edu> <227151856 DOT 20140421223417 AT yandex DOT ru> <21333 DOT 26515 DOT 393838 DOT 380071 AT compute01 DOT cs DOT columbia DOT edu> <20140422081628 DOT GC2339 AT calimero DOT vinschen DOT de> <21334 DOT 55207 DOT 784319 DOT 488271 AT compute01 DOT cs DOT columbia DOT edu> <20140423084056 DOT GJ2339 AT calimero DOT vinschen DOT de> <21335 DOT 61113 DOT 963950 DOT 516021 AT compute01 DOT cs DOT columbia DOT edu> <20140423172413 DOT GQ2339 AT calimero DOT vinschen DOT de> <22038 DOT 38637 DOT 802707 DOT 846218 AT compute03 DOT cs DOT columbia DOT edu>
MIME-Version:	1.0
In-Reply-To:	<22038.38637.802707.846218@compute03.cs.columbia.edu>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--rFUhhEVnhEf/dYhU
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Oct  8 12:16, Jonathan Lennox wrote:
> Hi, following up on this issue from last year.  The message I'm replying =
to
> is at <https://cygwin.com/ml/cygwin/2014-04/msg00524.html>.
>=20
> The problem is weird behavior in Parallels Desktop-hosted Windows VMs, wh=
en
> accessing the host's native Mac OS X filesystem.  See the thread for the
> details.
>=20
> On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "cygwin AT cygwin DOT c=
om" saying:
>=20
> > > At this point this is looking pretty clearly like a Parallels Tools b=
ug.
> > > I'll report it to them.
> >=20
> > Yes, that sounds good.  Given that, I'm wondering if we should try to
> > workaround this problem at all or rather wait to see if the vendor will
> > fix the issue.
>=20
> No such luck, despite two major version revisions of Parallels Desktop (I=
'm
> now on version 11.0.2) and moving to Windows 10 as the guest OS -- the bug
> perists, unchanged.  So it looks like Cygwin will need to add a workaround
> for this filesystem to fix the problem.

Ok, we could do that.  Can you compile and run the testcase from
https://cygwin.com/ml/cygwin/2014-04/msg00523.html again?  Does it
still show 0 vs. 12 bytes?  Dumb extra test: Does the output change
if you reorder the calls, requesting FileStandardInformation first,
FileNetworkOpenInformation second?

> The output of /usr/lib/csih/getVolInfo seems to be unchanged from the out=
put
> I reported last year.
>=20
> > Thanks.  This looks pretty much like a filesystem pretending to be
> > FAT-like.  There may be another problem lurking, which is, are the inode
> > numbers (called "FileId" or "IndexNumber" in Windows) persistant?  With
> > FAT this is not the case, and given the above, it might be a problem...
> >=20
> > ...or not.  I just realize that Cygwin doesn't even try to use the
> > FileId as inode number on filesystems with FILE_PERSISTENT_ACLS=3D=3DFA=
LSE
> > so, never mind.
> >=20
> > OTOH, does it support hardlinks?  If so, two hardlinks to the
> > same file would have different inode numbers on Cygwin.
>=20
> How would I figure these points out?

Just create a hardlink on that drive using native means:

  $ touch foo
  $ cmd /c mklink /h bar foo

Error at this point?  No hardlinks.  Otherwise:

  $ ls -li foo bar

Are the inode numbers identical?  Congrats, hardlinks work.  But given
the general FAT-iness of the getVolInfo output, I guess it doesn't
maintain hardlinks.


Corinna

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

--rFUhhEVnhEf/dYhU
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWJ3H1AAoJEPU2Bp2uRE+gUaIP/3GSfFlFw2N7AFjuFS6vtIFZ
bZXl7na4TE8gsQ5apNjq3TWvr10kUdgjEd/4W9RPq5gwQ9m+8YZ5MmflR1HXCE0w
KXXjO5B4Go3tPYXcXHOyU2vXGCnLtK0FmvDUhZBPuvuMHPZK7sYQZZ9wIizhTgU7
Q1DnxyKk88Oj52DLcGSaAho0/0+nziexxNyyl2qO3qh+ja1iFunKy2RPAVNDDeHo
lv3WOzxPK2nmjNehy5mTmkFrc+/B9k85Et9I+vOZgKSb4Omjy82EJA2El8PO/Ibk
Z99t8oIK2CC8UypeAvEhnn14FHXPJ1DlbUWHKDiZ5H0imPJrG+10LaK2eSIbwhfS
8EnEedZfsu8vEte6KUiohw7IdS/AGijurKbiWhjOUbp3EgHlEa6YIdML/oa6UcR8
H7TiWM7lgP++GBQTF6Vx483J+2f8oo8Yt/gMphGdTmgoJQESkVfvDRNNb7PMz35C
DuWiAJ+vbSUhLTLLz/JvIH/vAvdMb+RG5+dMyJDVGvoW9SSCvYReMRsePelI4ANU
AkRuzBt+2jBwWcOBbzVFxCir6Gn2Zr/FWr67qj5MuhcZF+X3YxdNovkrFINPCuA2
Fs9nNiapAo5dj4q589bZ5q5rJeHh5BC4s418Lx/iwB9UlCtVisKmWJWzBcx2iUDW
xLI5j3Su0bPLwoIwKrEf
=+hx+
-----END PGP SIGNATURE-----

--rFUhhEVnhEf/dYhU--

- Raw text -