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:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=GzITKgxjUrLuEm1D
	yuu1Si1oXzKPTRDDuoI3wSiVppK6luvouPKmG7LLAtiQ+Q1tVaQW3rU51J8qgF1F
	LpwAW8es27Zo9K5Xw/6IFGkqgFVhiofZkYqce90J31lzYyHSI0do2DlF7JJ1iB2q
	yRpV3aYz+Cgg0s70cSUqaIAG0t4=
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:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=zCMlJeHGPXJO25SVsJd6yE
	R85yo=; b=adzQXCqU59jL6E/3xzSp2/l5B+nfidpQQkAA+dlbw9ESUFPuhWvjH8
	N8tdSrNv7kD4RF1ncPpXsoqyOgVcK/OD4Dzm8kHS1yCmlxNhd5Fh5Wq0D/0uPU+U
	R6qdBPMHD5AFPXMsTrp/x71co0nh4d1NPACbcGYNkTQcERQDS2sfU=
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=-3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,KAM_THEBAT,LOTS_OF_MONEY,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:58C0D74, H*MI:sk:58A4741, H*MI:sk:2017021, H*MI:sk:58C0D74
X-HELO: forward5p.cmail.yandex.net
Authentication-Results: smtp2h.mail.yandex.net; dkim=pass header.i=@yandex.ru
X-Yandex-Suid-Status: 1 0,1 0
Date: Thu, 9 Mar 2017 16:37:24 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <1599023500.20170309163724@yandex.ru>
To: "L. A. Walsh" <cygwin AT tlinx DOT org>, cygwin AT cygwin DOT com
Subject: Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount
In-Reply-To: <58C0D744.2030005@tlinx.org>
References: <58A4741E DOT 5020408 AT gmail DOT com> <20170216092611 DOT GE3889 AT calimero DOT vinschen DOT de>   <58B0AA58 DOT 30504 AT tlinx DOT org> <20170228214321 DOT GB13542 AT calimero DOT vinschen DOT de>  <58C0D744 DOT 2030005 AT tlinx DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Greetings, L. A. Walsh!

> Didn't see a response to this, so reposting, as this
> would provide a needed vol and subdir mount facility as
> exists on linux...

> Especially, since there was a misunderstanding of what
> was needed or wanted w/regards to the JUNCTION file-system
> mounts in Windows.   Didn't need mount table updated, just
> needed it to look like a normal mount (as 1 of the 
> 2 junction usages already does).  So it's just a matter of
> making the other junction type w/a path be treated as
> a normal dir instead of a symlink.  As it is now, it's 
> inconsistent with junctions created with mountvol being
> different from junctions created with linkd.

> Symlink(D)s would stay as they are now and provide the
> symlink functionality.

I would argue against all junctions being treated blindly.
The difference with bind mounts in Linux is that in Linux you don't have the
information available within the filesystem itself, and have no other option,
than to treat them as regular directories.
Only direct volume junctions cause an issue, and this is what should be fixed,
if possible, not sidetracked with questionable workarounds.

> Original note:

> Corinna Vinschen wrote:
>>
>>>  They
>>> half-way work under Cygwin (junctions to volumes look like
>>> mounted file systems look under linux, but junctions to
>>> pathnames get converted by cygwin to symlinks -- losing
>>> information when such junctions are restored.
>>>
>>> Corinna -- could you _please_ re-look at supporting both
>>> types of junctions as mount points?  Then Cygwin could have
>>> "mount-parity" with linux! ;-)
>>>     
>>
>> That's not easily possible.  Mount points in Cygwin are virtual entries
>> stored in the per-user session, in-memory mount table. 
> ---
>    Ahh.. you are making it more complicated than what I'm
> asking! (yey! this should be simpler)...

>    If I have a junction to the root of another volume, in
> cygwin it looks like a normal directory:

> Using mountvol...

> C:\>mountvol mountedVol \\?\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}
> 03/02/2017  01:24 PM    <JUNCTION>     mountedVol 
> [\??\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\]
> 01/11/2017  04:17 PM    <JUNCTION>     var [C:\Windows\System32\cygwin\var]

> ### a junction is created ... under Cygwin. 
> Note, BTW, that 'var' is also a JUNCTION (a MS-mount point).


> C:\>exit
> exit
/>> ll
> total 100672654
> drwxrwx---+  1            0 Nov 20  2010 $RECYCLE.BIN/
> ...
> drwxrwx---+  1            0 May 15  2015 mountedVol/
> lrwxrwxrwx   1           28 Jan 11 16:17 var -> 
> /Windows/System32/cygwin/var/

/>> ls mountedVol
> $RECYCLE.BIN/  System Volume Information/

> ### mountedVol looks like a normal directory ^^^, but 'var' shows
> ### as a symlink.  That's the problem I'm referring to.  I'm saying
> ### JUNCTIONs (MS-mountpoints) should show up as the 'same' in
> ### Cygwin -- i.e. --

> ### But is not necessary that it be shown in Cygwin's "mount table":

/>> mount
> C:/bin on /usr/bin type ntfs (binary,auto)
> C:/lib on /usr/lib type ntfs (binary,auto)
> C: on / type ntfs (binary,auto)
> B: on /b type smbfs (binary,user,noumount,auto)
> ...

> ----
> It's the same on linux.
> linux> stat -c %D /var
> 822
> linux> sudo mount --rbind /var/rtmp /tmp
> linux> stat -c %D /tmp
> 822

> ----
> A mount from the same fs to another place on the same fs,
> looks like a normal directory (not a symlink).

> This is the behavior I would want for 'JUNCTION's under
> Cygwin. 

> On Windows, mklink creates a 'SYMLINK' or 'SYMLINKD' when
> directories are linked.  Those would stay as "Symlinks".









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



-- 
With best regards,
Andrey Repin
Thursday, March 9, 2017 16:33:49

Sorry for my terrible english...


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