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=WfaHaJEqjl9SwkUdZBvueXxexJUQVEcmnyOqebYmCLyGBoSAQyBJ1
	6jN0dvWCmfr0/+bN2av9AbY8iop8OzM0DvpFgEivT5kxqM3ej6usrOYQrF/QEM3c
	K/E6eq2kFVrCHWBPnJMBztUUS2hF6tEOUl5Mp0RKGYdBRSo++obWiQ=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Wed, 9 Apr 2014 19:26:54 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Request for Junctions be treated consistently
Message-ID: <20140409172654.GB22721@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <5336C0DF.5080102@tlinx.org> <5336C23B.2070309@tlinx.org> <20140331102745.GD23383@calimero.vinschen.de> <533AEBD6.3040209@tlinx.org> <20140402084026.GM2508@calimero.vinschen.de> <533FE56D.5010809@tlinx.org> <20140407092342.GF2061@calimero.vinschen.de> <1675705369.20140407220427@yandex.ru> <20140408083955.GA28755@calimero.vinschen.de> <53453800.9010603@tlinx.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG"
Content-Disposition: inline
In-Reply-To: <53453800.9010603@tlinx.org>
User-Agent: Mutt/1.5.21 (2010-09-15)

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

On Apr  9 05:07, Linda Walsh wrote:
> Forgive me if this posts a 2nd time, but I haven't seen it come
> back after 6+ hours, so not sure where it went.
>=20
> Corinna Vinschen wrote:
> >
> >No, it's not.  There's a major difference between mount points and
> >symlinks, which is, mount points are handled inside the kernel, while
> >symlinks are filesystem objects.  Reparse points are very certainly
> >filesystem objects.  And bind mounts in Cygwin are handled in the
> >"kernel" as well.  We can't add reparse points to the mount table
> >on the fly.
> ---
> Windows Internals V5, p965
> [snip]

I know how reparse points work, but thanks all the same.

> Theoretically, there should be a cental resource that would enable you to=
 know
> all the reparse points that are associated with mountpoints that wouldn't=
 have
> to be added "on the fly", but could be added to /etc/fstab on cygwin-init=
ialization.

I'm not sure how we came to discuss adding Windows mount points to
/etc/fstab, but either way, we don't want to do that.  It doesn't make
sense.  The Cygwin mount table provides a translation from Windows paths
to POSIX paths.  Adding the existing Windows device mounts doesn't add
any functionality.  Quite apart from the fact that Windows mount points
can change underneath Cygwin, so a fixed /etc/fstab containing Windows
device mounts is kind of moot anyway.

> But the one created with 'linkd' is called a Mount Point.

So because one Microsoft tool calls directory junctions "mount points",
they are mount points from a POSIX POV?

Again, we can't make the directory junctions POSIX mount points.  The
mount table is in memory and has a fixed, limited size.  The only choice
you have is to handle a directory junction as symlink or as plain
directory.  The latter is wrong since it's not a plain directory.  It's
just a file system object pointing to the real directory.  If you
handle it as directory, find and other recursive tools would enumerate
the directory twice, once via the real directory entry, once via the
reparse point.  And there would be no way at all from a POSIX POV to
distinguish the two.


Corinna

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

--1UWUbFP1cBYEclgG
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJTRYLeAAoJEPU2Bp2uRE+g/iAP+wTLayPTt4muZ0Z9EsaHiqVX
s9QwQzwnBv5CbZTbTMPpBGHPcb6AD4uJq0V4VZs3cllnQorP55ICw/G+KDTJDCS4
8ANNNp2lOvw/ZqcDKQv7KKGmqzgfx5gmcvdMRUJC4/O2w/VC2P3E8HjwOG8Rz21V
um+6ZR6lLgBAlFcx2e363rB6M5w4VrKt5Fl4kLyCXbhWsPMuupcccasc9rr2iH3w
w8fi8MLNW9z/X8iDQCehyldfBvaNXikg6CYC1DN8dpC4P64LHHGSb3CU7JFkdxBy
vZlAwI3RVMlOGgpD3AT+nAnDdzNpye35BJWq/A/XjO/SvJ7a/szVBuaU/euco/Ws
JUfjV5ann7O25Gu5aWqpCSyqWEmFsNQmTaLKZ9NF5Z9VFS4QEpNoJCSurVu/yrOy
9NbX56zeGIKdwDFsmxzivlFrLUk/ttvFjiZBCLHFdx/F4TG6TE/1aaMh9PK7rLCZ
hlZ0IiPwFKXhgFjS5/WVhG/Yp6xgWl5vJ7y3LhfpHZTkXAOj+wXvKkrywaXvAlA+
U5lFpTNetgziu2ko9vSyBrYa3d6Sl/nZB3vi1c3eZemngSTvNCr4If9LHOYCAR+e
GxSRWvgE0N+sc1KFEaP4gM2Siv34z512aP5/Rd8VCjofm/wRMIaIrzja0vkyed/1
uOjb9GDAKOnW95ltIDfZ
=vRTR
-----END PGP SIGNATURE-----

--1UWUbFP1cBYEclgG--