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=iiWVd8Uf4tnhbjuHFOfMtb5P0Qc6Vf7gx5irO3Jc9ffu6WL9x7/Fu
	X3aHk77b+H2io+D39yz9uoqKyNJMTj+X9WDEiGaT75dGnynLDXiMQ4xLWTt87dAG
	TgbgrR28bI5a6hgrqjQvRf+paERMuMLQlUU61bzGwUF9F0ZmX6w1BI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 17 Jun 2016 10:42:53 +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: <20160617084253.GH27295@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <D388F238.929F%billziss AT navimatics DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="u65IjBhB3TIa72Vp"
Content-Disposition: inline
In-Reply-To: <D388F238.929F%billziss@navimatics.com>
User-Agent: Mutt/1.6.1 (2016-04-27)

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

Hi Bill,

On Jun 17 07:25, Bill Zissimopoulos wrote:
> > How are you dealing with limitations of the Windows file system as seen
> > from a POSIX perspective? You say you can't support hard links.
>=20
> Windows hard links are rather un-POSIX like and rarely used on Windows.
> After considering the required changes on the FSD for a feature that is
> so rarely used I opted against supporting them.

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.

Hardlinks are pretty essential I think.  The API from user space is
rather simple as well (NtSetInformationFile ([...], FileLinkInformation)
and supported in Cygwin for the link(2) call practically since the last
century :)

> > How will a Cygwin program see symlinks exported by the FUSE file system?
>=20
> WinFsp will present symlinks as reparse points. Cygwin already knows how
> to deal with NTFS reparse points and it will present them as POSIX
> symlinks.
> I may even relax the whole =E2=80=9Cyou have to be admin to create a syml=
ink=E2=80=9D
> nonsense.

Full ACK!

> Please note that WinFsp does (not) yet support reparse points. There is no
> big obstacle in the way, just a question of time.
>=20
> > And pipes?
>=20
> Pipes in Windows are not stored in the file system, rather they are
> implemented by a special Windows file system called NPFS. OTOH POSIX
> FIFO's are special files. I am unsure at this time how Cygwin represents
> FIFO's.
>=20
> [Quick experiment:
>=20
> $ mkfifo foo; cmd /c dir 'foo*' | grep foo; rm foo
> 06/16/2016  11:02 PM               130 foo.lnk
> ]
>=20
> Ok, so they are shortcuts. Naturally they are supported.

...just the FIFO implementation itself... let's just say, it could be
improved.

> > You write that you are mapping
> >  - characters not supported by Win32 but by POSIX via the Unicode
> >    private use page
> >  - Security apspects (SID vs. uid/gid, ACL)
> > between POSIX and Windows and that you do it like Cygwin/SFU/SFM is
> > doing it.
> >
> > But if that's done by your code, a Cygwin process may see slightly
> > different mappings through WinFsp and through Cygwin. Won't that be a
> > potential for Bugs (misbehaving apps) or even for security issues?
>=20
> I agree that the potential is there. But I did not want WinFsp to depend
> on Cygwin so reimplementation was the best option for me. Additionally
> Cygwin does not expose this functionality to third party apps AFAIK.

Uhm... I don't understand.  Cygwin is using the private unicode range as
well to map characters invalid in a Windows filename (e.g. colon 0x3a is
mapped to 0xf03a).  This is how such filenames are given to the OS function=
s.

This means, WinFsp would get these filenames from a Cygwin process
already in the transposed form, with invalid FS chars transposed into the
private area.

If WinFsp would support that, it would be transparent to applications
with very minor effort.

> Try this from a cmd.exe prompt:
>     type \\?\GLOBALROOT\Device\HarddiskVolume2\Cygwin64\Cygwin.bat

Or thhis from Cygwin:

  /proc/sys/Device/HarddiskVolume2/Cygwin64/Cygwin.bat

:)

> For this reason alone, I expect that most user mode file systems
> will be packaged to work as network file systems.

That would make a lot of sense, I think.


Thanks,
Corinna

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

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

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

iQIcBAEBCAAGBQJXY7gNAAoJEPU2Bp2uRE+gCW8P+wSfbIJyAQU94JcPHU51oVQB
zg1a4CJL4J7pEsgwwfc5d/cLAUkJUpZIFSwm7LuR1VebuMceKedwCHodCx7Ryloz
3CGy9xqj/6/XA/o/gtMX5WO6QxIdqGf5py58UOso33KXEg7Gm3DpAe/bHdmMPiSy
yRR66C+ITJl8TNNLRRi4paZqRhBBvuux+4kwC51IMLA2cCmck50aBQjjanlmOoG9
6M6MjHUGmDCxZ0NEUHTr0TELj37qdjrRwGzfrO6LwplPuXycqdXZvbB5wEjJspKH
h9MdAu8fXXJ1/gw0ap9qGJcl42y+QhG3baebnhiOmRbx3U+EK/mecDySWnHvRwB0
o5XcNxroro0vOgYjd2b7KrTkRlCVWbQnkJ53dQ+QSLzm7X7RoXeBTE+x3kqJWQVa
dbUKIZOXM9yPJ1DxL3Q0YS5SlqafKesYXWejyOSfLsMTe0Css2EL7+IlVcjjaZ2V
wyyKqUETfhaIzwjNNH+44kCcsVMo3LYaJk9lSNnQ5kin85KtPkMDksssbOlOGXFH
wtWWrV2pvXw01mmHW0ioawDPQww05qS590EhEXVEbzlHcSHkYyPHLKfbbRF3u9gL
Q/7e7paSTUYgCEnHr6/BQCMoo1kORl9mctzHJSnQIPi1wGNU3qZOArIpBKPEc7PJ
3+GjnQRMtcE7cY+5BoFX
=wU/E
-----END PGP SIGNATURE-----

--u65IjBhB3TIa72Vp--