DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=FytnXwwX5C0GVpYuIQejAlLLtKeUqudY9yci4DaSaGb
	R5edq2MnVAUJnWwllZO73qzDjqr7pMYTn+c6ZfeQaPnRRgrPDPR45+rVB/7GIqZw
	SobRXy5mqIdbpRzgPvkNXTPvIs7Yp//kh+YRKAOLk3+sNGfJQzoLokIBEy3IB3rI
	=
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
Message-ID: <58C48EF9.4050106@tlinx.org>
Date: Sat, 11 Mar 2017 15:57:45 -0800
From: L A Walsh <cygwin AT tlinx DOT org>
User-Agent: Thunderbird
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks
References: <58C31431 DOT 1020408 AT tlinx DOT org> <5110401945 DOT 20170311210154 AT yandex DOT ru>
In-Reply-To: <5110401945.20170311210154@yandex.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Andrey Repin wrote:
> Greetings, L A Walsh!
>>     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?
---
	Are you not suggesting treating JUNCTIONs the same
as SYMLINKs and treating them *both* as 'symlinks' in Cygwin?


>>     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.
---
	Please clarify -- but it seems you want to
disregard the differences between JUNCTIONs and SYMLINK[D]s.
Is that not so?  How is that insinuating?


> That's a reason for bug reporting.
---
	I have brought it up before.  It is considered
standard for some installers to check where they are being
installed.  As near as I can tell it's cygwin treating JUNCTIONs
as *nix "symlinks" that is the problem -- thus my request that
JUNCTIONs not be treated identically as Win SYMLINKs.


> We're not talking Linux or VirtualBox issues here, do we?
---
	I'm, talking parallel features and parallel problems.
Installing products on Linux or cygwin may check for and
complain about symlinks leading to their installation directory.

	The cure in both is to use bind-type mounts and
remove any symlink usage in their base path.


> Cygwin is not Linux. I don't see why you're operating Linux
> arguments in the native Windows area.
----
	I am using "problems & solutions" from linux to
refer to similar problems and solutions in Cygwin.


>> ls: cannot access //?/: No such file or directory
> 
> />> cmd ;  C:\>dir \\?\  ; dir \\?\
>> The filename, directory name, or volume label syntax is incorrect.
> 
> That's ls problem.
> That's CMD problem.
----
	So you say that neither Cygwin's nor Window's utils
understanding your syntax is *"their"* problem?  *sigh*


> You're again substituting meanings with no clear 
> understanding of the issue or consequences.
> 
> 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".
----

	JUNCTIONs are created by 2 utils and are of 2 types.
One is created by "mountvol" (which is the one used by you),
which works (as you appear to be showing in your image link).
The other is created by 'linkd' or some similar util, which
allows one to bind an NTFS-path to a directory on inside an
NTFS volume.  You are making no use of the 2nd form -- and it
is the 2nd form that is the problem.  It's being treated as
a SYMLINK by cygwin.  

	MS added SYMLINKs after JUNCTIONS and Cygwin uses
those SYMLINKS (when ENV{CYGWIN} has 'winsymlinks:native'
in it) to provide a direct Cygwin->MS mapping of 'symlinks'
to the underlying Windows feature of 'SYMLINK(s) (& SYMLINKD
for directories)


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

	From:

https://technet.microsoft.com/en-us/library/cc938934.aspx

"You can add volumes to systems without adding separate drive letters for each new volume, similar to the way Distributed file system (Dfs) links together remote network shares. Volume mount points are robust against system changes that occur when devices are added or removed from a computer. "

It goes on to say 'mountvol' is a way to manage volume mount points.
	From:
 
https://msdn.microsoft.com/en-us/library/aa365006%28v=vs.85%29.aspx

"JUNCTIONS
A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer. Otherwise, junctions operate identically to hard links. Junctions are implemented through reparse points."

MS, initially called JUNCTIONS 'mount points' and later changed
the nomenclature to call them "Soft Links".  

From https://msdn.microsoft.com/en-us/library/aa365680%28v=vs.85%29.aspx

"SYMBOLIC LINKS...
Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented its symbolic links to function just like UNIX links. ...

Symbolic links are available in NTFS starting with Windows Vista."

SYMLINKs -- are the equivalent of UNIX symbolic links.  The 
**Soft Link** feature is equivalent to a mount-point and is implemented
using a *reparse point*.

The reparse, Soft Links can also introduce a cache coherency problem
as in:
https://blogs.technet.microsoft.com/asiasupp/2010/11/03/mounted-folders-disappear-in-shared-folder-after-navigating-to-them-in-windows-7/

There they have workarounds, including "mounting subdirectories under
a volume rather than mounting the root of the volume"...


There are a bunch of references pointing to *REPARSE* points being
designed as *mount points* in MS.  


For backup purposes, they also describe how to detect junction
points.  From:
https://msdn.microsoft.com/en-us/library/bb968829%28v=vs.85%29.aspx

  "These junction points can be identified as follows:

    They have the FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_HIDDEN, and FILE_ATTRIBUTE_SYSTEM file attributes set.
    They also have their access control lists (ACLs) set to deny read access to everyone.

Applications that call out a specific path can traverse these junction points if they have the required permissions. However, attempts to enumerate the contents of the junction points will result in failures."

NOTE -- they mention that backup apps must detect the empty dirs and
not try to proceed as that can cause duplicate items in backups or
filesystem 'cycles' (loops/circular references).


So note, the volume mount points that you are already using would
not be changed.

The only change would involve where a REPARSE point doesn't point
to the root of a volume (necessary to get around the bug mentioned
above).  I.e. pointing a JUNCTION at a volume+subpath won't trigger
the bug mentioned above.


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