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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=IbFZ9pf2mnVeLyf7
	BSwJRIVIN5PeHFUX99IkCukQsr9OTJH1lKOt2PHj1/xxjSw42TdrY8Z3p/r+Jof4
	L+AlBezx440qu6KP23QPzAAr6Rz/mua5JCrEDeZXXd1UyYisSA1qPugYEs/xp5Fr
	PRErLfgtbO8PHpcNJJlmisDF0JY=
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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=nvCZtoN0uyoe8iAXiGn11w
	ZBfew=; b=oeGF7w5NvJNiNGRkkKAaaQw+4OEn+xmBb2WTNR5EkTfxGB62wHrLor
	n7vCeEySDceuBDw4rCh5W8ifJhlxaJw5NrizP8IT/vmCyt7sBLy6R6oLGgSLipPG
	q1ww7eD62LN/6IFOxRe6i6Uh1FJ78vHpuO1rdAANUYp9b7lZ7ZSqk=
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=-0.5 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=one!, citizens, faces, sk:casein
X-HELO:	mout.gmx.net
Subject:	Re: FUSE for Cygwin
To:	cygwin AT cygwin DOT com
References:	<D389ABB9.931F%billziss AT navimatics DOT com> <57667FEF DOT 5070801 AT gmx DOT de> <D38C1E3D.9385%billziss AT navimatics DOT com>
From:	Herbert Stocker <hersto AT gmx DOT de>
Message-ID:	<57670140.7050001@gmx.de>
Date:	Sun, 19 Jun 2016 22:32:00 +0200
User-Agent:	Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version:	1.0
In-Reply-To:	<D38C1E3D.9385%billziss@navimatics.com>
X-UI-Out-Filterresults:	notjunk:1;V01:K0:h3+UuKfMukI=:ugqGocEnxYdJP04WPpz5k+ sG23PPFKThWdyLUibRYqBA3kl93BIu2RFqHag+/z71wW80/hmJhfUe/2lsZr0aMqumNG0Rjms nbA/4fRF2ronBGtaqroy4v2JqhGw1Xzb8uTY7vvQm8EugI/X57+ZeQPAv7ZO5HKupA86uXzt6 ATrHbAIC/dolIYbV46q7JXBlpTCdz8jqVigYIIC6tb3eUI0jSzgkU2Gpw4Xg482P2o5+ryiLL kfxXcaNr23QPzoBfgEfaUQ2q64CgSFyOi7w3g7pJ4sxneOuZlGxSp+3GmIWPLsaFaBBoJvBtk hBuLYgq88cm1xEqcPrMO6JAvFML4Mc1g5g+wI+iAqm8DRZQ+8AXGMvwITh/G6N5MsW3OJITwD QO3ulY5I0OR1dfet0JcleaR3ir7fWVmAj/Ug+ZgM2DmQPSyAlJ6boYtbtWPPPUkNI+UHUc9fQ 6BWLHc49MzFOPY3TsKbBCxMyniT+gPQkpoJbs5Z9MvOEKaa8q1crCFyz0fvz6H6aGzDrZVWGj gW5saQoSIS5DluWcdVfeAzD5W0co/f/aMFnYdfUMzAUqvVZeKDHMOuTcjWdKOHUIlnu+Xfk18 i4o5pkHiOWG/JAPqHx6Hrew9FD9UZ8XS+IFGZtoiBZmx0qlIMemHGpnSUsoZxGsf/RBuBDFm5 c39hK8q7pkgyieIwyrrrxuDnLrDaKKNjCpaq00zF+iat70jT5EkZF6KsLEyNcQirUpet2TXvu f05RUbeqYzJJr3oBVIvgVLReFf2HmrMO5LgEif9XPShJN7nabO78ubkE7lnCaGtckRxrT0pFp uLbMLNF
X-IsSubscribed:	yes

Hi Bill,

i agree with you that there are only two context switches involved
and that Cygwin processes are not 2nd class performance.

But i was *not* talking about context switches.
i was talking about *translating of semantics* mostly in my mail.

Because i was trying to avoid translation from Posix to Win32
*and back*, just to go from Cygwin process to Cygwin process.

And the reason i want to avoid the translations is not performance.
It is because mode (4) does not have those issues that WinFsp must
take care of in (3). See my points B) to G).

Please also see the end of this mail, i overlooked something you did
not. So i'm now more biased towards (3).


Now some specific answers:
 >> E) Same for uid/gid to SID mapping.
 >>    No need to implement or follow Cygwin.
 >>    And how about the case where a uid/gid has no correspoinding SID?
 >>    Can this happen?
 >
 > Yes, it can, but this is an issue that Cygwin faces itself.
 >
It will not face it if communication between both Cygwin processes
does not leave Posix semantics. See what i try to avoid?


 >> F) Pipes:
 >
 > Good catch this one!
 >
 > Of course I can try to fix this in the WinFsp/FUSE layer
 > implementation, but the fix would probably be a gross and
 > Cygwin-specific hack.

Mode (4) would avoid such things *by design*.
Not because we happen to catch all of them.


>> To fix this with mode (3) you'd have to recognize these .lnk
>>    files and forward them to the file system as pipes, and you'd
>>    have to generate .lnk files on the fly when the file system
>>    says there is a pipe file (e.g. on readdir).
>
> Yes, I agree. Not pretty!
>
But please do that if you stay with mode (3).


>> G) Case sensitivity.
>
> WinFsp (and Windows) allows for both case-sensitive and case-insensitive
> file systems.
 > <snip>
> FUSE file systems are marked as case-sensitive by default.

If WinFsp marks FUSE file systems as case-sensitive then there is no
issue with case sensitiity.

However we should have a look into OSXFUSE, it also has to deal with
case sensitivity. Let's see how they solved it. There's also MacFUSE
and Fuse4X according to Wikipedia.



> Just to clarify: I believe that Cygwin processes are already on the same
> class as Win32 processes when it comes to a WinFsp exposed file system.
> There are no extra context switches

Context switch wise they are the same class. But i was not concerned
about context switches.

> Even if you created an intermediate Cygwin process (that
> acted as a WinFsp file system) to let Win32 processes access these FUSE
> file systems,

That was defintively my aim. And i think we should use WinFsp for that.

> you would now make those Win32 processes 2nd class citizens,
> as they would have to go through that intermediate process (which means 4
> context switches per file system request for them).

You are right. I did not think about this extra process. Performance
wise Win32 processes would be 2nd class. i was just thinking about
feature wise, where they don't lose.


 >>>>>>>
Now this argument of yours makes me more biased towards mode (3). Let's
pay with some design unprettiness (remember pipes) and have the better
performance for both worlds.

And besides, the translations are necessary anyway for mode (2).
Except for the pipes and hardlinks, they need not be supported in
mode (2).


best regards,
as before, i am looking forward to use WinFsp and have FUSE available
for my Cygwin scripts and stuff. And even for windows processes.

Herbert




--
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

- Raw text -