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=RevZCcrkVB4WwZ5i/bM3QgEzSAQKDh9+BqDJpw4IkvMkR/lQWZlId
	7Ey4/+nCjChiBj2QMnVff4E0AkWBZ0ptPM6WmnbKW8at0Eb+wGXKK8KfiyP9ggcY
	uQkfzGiecDU5KaGt6itMOPMm1uOsZXBtW+y/IzEQr7oP5egTSuXPM4=
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=TqNzr8OCyRAnXtuP7iw2s7lTpbw=; b=Bz8reQ0AckSFJeYjd9hjyFQTlWFH
	shYkJHac763wMGPIVPQnTYrGkW11UTfSj2dcAshARZLg5k2zvrRHhPvmWYnin6J4
	yYJT+X8EXeQjUxtc1R1zLhk8VzmmdiYj6LPmMMgFh1+C21VgqeO0x+xUsDUMCQDB
	/vpEv4gZ/IfAAEY=
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=-96.3 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=H*f:D389A1FE.92E9, H*MI:D389A1FE.92E9, H*i:D389A1FE.92E9, perfect
X-HELO:	calimero.vinschen.de
Date:	Sat, 18 Jun 2016 10:02:35 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: FUSE for Cygwin - was: Re: Fork and Windows Heap
Message-ID:	<20160618080235.GA3332@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<D389A1FE.92E9%billziss AT navimatics DOT com>
MIME-Version:	1.0
In-Reply-To:	<D389A1FE.92E9%billziss@navimatics.com>
User-Agent:	Mutt/1.6.1 (2016-04-27)

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

Hi Bill,

On Jun 17 19:48, Bill Zissimopoulos wrote:
> Hi, Corinna:
>=20
> On Jun 17 07:25, Bill Zissimopoulos wrote:
> > > Windows hard links are rather un-POSIX like and rarely used on Window=
s.
> > > After considering the required changes on the FSD for a feature that =
is
> > > so rarely used I opted against supporting them.
> >=20
> > I disagree here.  Windows hardlinks work fine and pretty much as on
> > POSIX with the exception of DOS mode bits.  Those are not per file but
> > per file entry as far as my experiecen goes.  One of the reasons we try
> > to ignore them as much as possible.
>=20
> I no longer remember all the details now, because it was a few months ago
> that I looked into this and determined that hard links are "un-POSIX like=
".
> As far as I recall there was the FileAttributes issue (which I now think
> may have been my incorrect understanding of the documentation), but there
> was also the issue of FindFirstFileName/FindNextFileName, which is not
> something that POSIX supports out of the box (AFAIK).
>=20
> Regarding the FileAttributes issue. The Windows documentation seems to
> suggest that they are stored with the file and not the directory entry.

Yes, you're right.  Apparently I didn't really think when writing.  The
*real* issue with DOS attributes is that they are per file :) That has
implications if you have multiple hardlinks to symlinks of the "Windows
shortcut" type, but that shouldn't affect your WinFSD.

> The bigger issue is that the FSD now maintains an internal table of open
> files that is indexed by file name. It actually started as a table of open
> files indexed by IndexNumber (inode number Windows equivalent),

Yeah, Cygwin is presenting them as i-node numbers.

> but I
> eventually had to change it for a number of issues (notably Rename
> support).

For rename support you can use the index number as well, usually,
since you can open a file by index number.  At least on NTFS.

> I am not saying that it would not be possible to change this
> part of WinFsp, I just believe that it is a non-trivial change at this
> moment.

Ok.

> [...]
> Let's examine the lifetime of a call to creat(). Suppose a Cygwin process
> does creat("/cygdrive/z/foo*bar"). In the following OP is the "originating
> process", CW is the "Cygwin runtime", NT is NTOS, WD is the "WinFsp FSD",
> WL is the "WinFsp DLL", FL is the "FUSE layer", and FS is the "user mode
> FUSE file system".
>=20
> OP: creat("/cygdrive/z/foo*bar")
> CW: NtCreateFile(L"<DEVICE>\\foo\xf02abar")     <--- Cygwin translation
> NT: IRP_MJ_CREATE L"\\foo\xf02abar"
> WD: FspFsctlTransactCreateKind L"\\foo\xf02abar"
> WL: FSP_FILE_SYSTEM_INTERFACE::Create L"\\foo\xf02abar"
> FL: fuse_operations::create "/foo*bar"          <--- WinFsp/FUSE
> translation
> FS: somehow satisfies fuse_operations::create
> [snip return path]
>=20
> The opposite happens when the file system communicates a file name back
> to the originating process, as in readdir().
>=20
> OP: readdir("/cygdrive/z/")
> [snip call path]
> FS: fuse_operations::readdir response: "foo*bar"
> FL: FSP_FILE_SYSTEM_INTERFACE::ReadDirectory response: L"foo\xf02abar"
> WL: FspFsctlTransactQueryDirectoryKind response: L"foo\xf02abar"
> WD: IRP_MN_QUERY_DIRECTORY response: L"foo\xf02abar"
> NT: NtQueryDirectoryFile response: L"foo\xf02abar"
> CW: readdir response: "foo*bar"
> OP: receives "foo*bar"

If I'm not missing anything crucial, that's pretty much exactly what we
need.  The Cygwin process reads and writes the file as if the '*' is
a valid character and the entire process of mapping is completely
transparent to both sides.  Looks perfect to me.


Corinna

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

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIcBAEBCAAGBQJXZQAbAAoJEPU2Bp2uRE+gYX0P+wYochfUDeqbHiIMXzMQH79t
QiKKNJ0zH3Da4Xc2wwC3u5H8+IWkXME/1NUHg5Fnhug2UaYzpbh9PqobZn3TPuYY
T2zm0vaCH/gLg21v9nzfRABSoVDOZ8GipkeRVBHQpjFpo3bn3OwvIPlrH8uhTvXG
YtFZN1Tju28q+vEc/4J92W290Tj4PTG7pYFoHxVJztZyhw6pKf776JHMJyJV6WfG
bUM+zTsj5avVjIZT+ibYyODbe/C7bhVZmVa0AGlfVFeY0aNr9hkaN4Fyb8d2AQaK
p50JDN5gfgiaGwIJxsCMpn4ATPb/jSUgdMpO0ALKEjVe8HMqjd/v0Ue0ZNy3jN9l
+sb3zrUa2UCPi6gcMUP110eH18kfAojHrxkWZtQW/g/ufWX9oO0nf5YZlQoK9sYF
sptOtqYaZLxB0uYGNQ+SOEG56gb7y/6pBFhVLXysppOaWQqYJwaGJxy5x9jhNhHQ
q4aCrsiZZ4XYpqLCdTApyoSgslFUeKsYYGlECnkqE1BI4EfAuG4QLhjCFc0HIpf9
DY3MLc7wRFXF0bB7cDtPnXaYCNqDPesfe24pnhu8afQDTjNMQbnDOYYTTGE3iItT
Fap9Pv+Cluap0RYK2AGV1dhZz5JAkaFmvRHkqMJMVOZ1kZ2b+X52+ChPhC1dSHN/
VH1ES9mhRVC12Al3G4LR
=/4Ld
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--

- Raw text -