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=e+J+vqkRK1vcdYKt
	bFeo/ya0PvtzZzxACg3LR21P/+KIJfllN7czqP2Q58OuJhJ+wKqr6mb1A1HejeeB
	al3fBWtoI1rXVPeeaVw9GwUVeaZdHu4YcFbgfMMjnQciAI8m6fTt7yJ0u+G43TQ7
	MumO6/R2hqq2aEF227+pQau5pW8=
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=97Xti+WOoWlSywZjDAVV3K
	RYpys=; b=HAdJTEtsFP6NC4adHieipwZb+ndQUX5rNpRWb4gATqjPlNyqvCkeRr
	ZfM7VxrxV+zg5vPlQf89s/iMIaVm/5g9e8hBp/JBTXcqR8MXsIK0FFoDW9llaIkH
	Loru35MyENieIu7Cq5nTClj3FSi04mhGwVpbhEKTy0zQmrJ1ZU9Pk=
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=-5.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,KAM_THEBAT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=slip, fighting, Been, gallery
X-HELO:	forward4o.cmail.yandex.net
Authentication-Results:	smtp2o.mail.yandex.net; dkim=pass header.i=@yandex.ru
X-Yandex-Suid-Status:	1 0,1 0
Date:	Sat, 11 Mar 2017 21:01:54 +0300
From:	Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To:	cygwin AT cygwin DOT com
Message-ID:	<5110401945.20170311210154@yandex.ru>
To:	L A Walsh <cygwin AT tlinx DOT org>, cygwin AT cygwin DOT com
Subject:	Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks
In-Reply-To:	<58C31431.1020408@tlinx.org>
References:	<58C31431 DOT 1020408 AT tlinx DOT org>
MIME-Version:	1.0
X-IsSubscribed:	yes

Greetings, L A Walsh!

> Andrey Repin wrote:
>>  Greetings, L A Walsh!
>>
>> > Andrey Repin wrote:
>> >> 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.
>> > ----
>> >         Could you describe the benefits of your proposed solution?
>>
>> >         You do know that MS originally called junctions "mountpoints",
>> > right?  So why would cygwin treating them as such be a "questionable
>> > workaround"?
>>
>>  How they are called, and how they behave is a two different questions.
>>
>> >         How would you want to treat them?
>> >         Could you describe the benefits of your proposed solution?
>>
>>  Easy way: As symlinks, just like now, unless it's a volume
>>  mount point that can't be normalized to a disk letter.
> ----
>     You say that throwing out the MS-designed ability
> to mount a filesystem subtree and treat them the same as another
> feature they added, "symlinks", is a benefit?

Where did I said that?

>     Sorry.  But throwing out useful features is not
> a benefit.  I asked for a benefit.  MS designed JUNCTIONS as
> 'bind' mountpoints.  That was an added feature added in WinXP
> and Windows2000.

Again, don't confuse design goals with implementation realities.

>     They added symlinks in Vista to create a feature,
> similar to *nix symlinks.  I don't see how throwing out mount
> points is anything but a BUG -- a removal of a useful feature.

You're insinuating.

>     I want to be able to mount other areas of other file
> systems onto directories.

Anybody trying to stop you doing so?

> Symlinks are destroyed by Cygwin's SETUP.EXE and the install process For
> example. I have a smallish "/usr" partition, but a large "/Users" partition.
> "/usr/share" grew to hold more and more data over time, and
> currently is using 16G, all by itself.  My "/usr" partition is
> 15GB with 4.7GB free, 11G used.  So I needed to split
> "/usr/share" off to somewhere else.  I don't have room for another
> drive, but I do have room on "/Users".  So tell me,
> why shouldn't I be able to create "/Users/share" and mount
> "/Users/share" at "/usr/share"?

That's a reason for bug reporting.

>     Same problem under "/opt" under linux.  "/opt" is
> a directory on my root partition.  When I wanted to
> install "VirtualBox" (which lives under "/opt/VirtualBox" it
> refused to run from a path that had a symlink in it.  How
> would you solve that?

We're not talking Linux or VirtualBox issues here, do we?

>     I used a 'bind' mount.  VirtualBox rejected
> symlinks in its base path, but it does work with mounted
> filesystems.

>     In the same way, not only Cygwin's "setup.exe"
> but also many of the "install" scripts that install programs
> under cygwin, check to see if there is a symlink as part
> of their base path.  If they find one -- they remove it
> and re-create the directory where there used to be a
> symlink.  Result: "/usr/share/man/man1/newprog1.gz"
> s all alone under 'man' as "/usr/share/info/newprog.gz"
> is by itself under /usr/share/info.   Where did the rest
> of my files go?

>     They are still there -- but under
> "/Users/share/...".  That's my main problem.  Cygwin
> doesn't install things in "/usr/share/<location>/<prog>"
> But first, removes all existing symlinks in its base
> path.

>     Without the ability to mount /Users/share
> (or /Users/opt) at /usr/share and /usr/opt, I have
> no way to manage the space on my devices.

>     So how would a Windows or Linux user solve
> the problem?  They'd use the OS's built-in 'bind-mount'
> feature (called 'junction' in MS-speak).  Because
> junctions are meant to be a way of splicing part of
> one file system into another at a specific path.

Cygwin is not Linux. I don't see why you're operating Linux arguments in the
native Windows area.

>>
>>  Preferred way: Fix volume mounts accessibility
>>  \\?\{UUID} -> /dev/disk/by-uuid/UUID
> ----
>     Sorry, but \\? is not a valid Windows path:

"\\?\" is not a "path", it's a "notation".

>>  ll //?/
> ls: cannot access //?/: No such file or directory

That's ls' problem.

/>> cmd
> C:\>dir \\?\
> dir \\?\
> The filename, directory name, or volume label syntax is incorrect.

That's CMD problem.

> Your suggestion doesn't work under windows,

You'll be surprised, if you really think so.
http://project.rootdir.org/gallery/web/?show=20170311-204648.png

> -----
> Show me how I can create a path that must have
> symlinks in it, that won't be removed or changed
> by cygwin's setup or other cygwin programs.

> With JUNCTIONs as a mount point, problem solved.
> With JUNCTIONsJ equated to symlinks -- paths are
> corrupted.

You're again substituting meanings with no clear understanding of the issue or
consequences.

> If you want to provide a Windows-compatible way to
> mount a file system+path at another path, fine.
> But reverting JUNCTIONs to their original mount
> functionality does work.  So, again, I ask you,
> how does your change benefit anyone (other than you)?

I don't quite understand the issue you are fighting over, right now.
In terms of *NIX, the closest possible meaning of junctions and volume reparse
points is "symlink".
You can't change this, it's core OS functionality. Trying to masquerade it is
one way road to hell. Been there with PHP's "realpath", I don't want Cygwin to
slip the same road.

> If 'bind' mounts were not a significant benefit over
> symlinks in linux -- they wouldn't have been implemented.

There's no "mounts" in Windows, other than Cygwin bind mounts written in
fstab.


-- 
With best regards,
Andrey Repin
Saturday, March 11, 2017 18:41:08

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

- Raw text -