Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

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

    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.

    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.

    I want to be able to mount other areas of other file
systems onto directories.  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"?

    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?

    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.

>
>  Preferred way: Fix volume mounts accessibility
>  \\?\{UUID} -> /dev/disk/by-uuid/UUID
----
    Sorry, but \\? is not a valid Windows path:
>  ll //?/
ls: cannot access //?/: No such file or directory

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

Your suggestion doesn't work under windows, but
JUNCTIONS do work under windows:

C:\>dir \var
dir \var
 Volume in drive C is System Disk
 Volume Serial Number is E889-68E4

 Directory of C:\var

03/06/2017  12:35 AM    <DIR>          .
03/06/2017  12:35 AM    <DIR>          ..
10/24/2015  10:20 PM    <DIR>          cache
07/11/2015  10:22 PM    <DIR>          cron
10/11/2014  07:17 AM    <DIR>          empty
09/18/2014  03:57 PM    <DIR>          games
01/11/2017  03:29 PM    <DIR>          lib
03/06/2017  12:29 AM        21,767,776 locatedb
01/12/2017  07:03 AM    <DIR>          log
01/29/2017  11:59 PM    <DIR>          run
01/29/2017  10:06 PM            65,536 syslog-ng.persist
01/17/2017  03:15 PM                 5 syslog-ng.pid
03/06/2017  12:29 AM    <DIR>          tmp
04/28/2014  11:34 AM    <DIR>          varnish
               3 File(s)     21,833,317 bytes
C:\>dir \|grep var
dir \|grep var
01/11/2017  04:17 PM    <JUNCTION>     var [C:\Users\cyg_var]

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

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

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





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

Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[cyg Simple]

On 3/10/2017 4:01 PM, L A Walsh wrote:
>    I want to be able to mount other areas of other file
> systems onto directories.  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"?
> 

Linda, I'm not trying to reject what you're saying which I find very
sound.  But for this scenario why not just use an entry in /etc/fstab
similar to the below example?

# $ represents original mintty
# % represents the elevated bash
$cygstart --action=runas bash
%cp -a /usr/share /cygdrive/c/Users/
%mv /usr/share /usr/share-bak
%mkdir /usr/share
%vi /etc/fstab
:$
o
c:/Users/share /usr/share ntfs binary,posix=0,acl,user,notexec 0 0
<esc>
:wq
%exit
$ mount /usr/share

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

Have you considered the Windows mountvol to resolve this issue?  Using a
similar example as above you could use mountvol to assign a VolumeName
to [A-Z]:/Users/share as e.g. S: and modify the /etc/fstab entry to:

S:/ /usr/share ntfs binary,posix=0,acl,user,notexec 0 0

-- 
cyg Simple

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

Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[Andrey Repin]

Greetings, cyg Simple!

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

> Have you considered the Windows mountvol to resolve this issue?  Using a
> similar example as above you could use mountvol to assign a VolumeName
> to [A-Z]:/Users/share as e.g. S: and modify the /etc/fstab entry to:

> S:/ /usr/share ntfs binary,posix=0,acl,user,notexec 0 0

The very idea to not use disk letters is to not use disk letters.
Assigning disk letters to volumes defeat the original idea.


-- 
With best regards,
Andrey Repin
Saturday, March 11, 2017 21:02:39

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

Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[Andrey Repin]

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

Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[L A Walsh]

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

Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[L A Walsh]

cyg Simple wrote:
> On 3/10/2017 4:01 PM, L A Walsh wrote:
>   
>>    I want to be able to mount other areas of other file
>> systems onto directories.  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"?
>>
>>     
>
> Linda, I'm not trying to reject what you're saying which I find very
> sound.  But for this scenario why not just use an entry in /etc/fstab
> similar to the below example?
>   
----
    I want my filesystem views between Windows and Cygwin to be
the same, as they, for the most part, are as I have:

 > mount -p
Prefix              Type         Flags
/                   user         binmode

So in cygwin /m/foo == M:\foo in windows and
//server/pathname in cygwin == \\server\pathname in Windows.

I use cygwin to manage my windows installation to some degree.

BIG NOTE -- in case people didn't know about this, but
with Cygwin64, all of the cygwin tools can be run in
Windows(x64)' repair console.  This was not true for
cygwin32 as it required a separate subsystem.   But this
allows for all the power of the *nix utils/env when
repairing/restoring a windows system.   A HUGE upgrade
in features & flexibility.


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

Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

On Mar 11 15:57, L A Walsh wrote:
> 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.

As I wrote (multiple times now?), we can handle dir junctions as
symlinks or as normal directories.  We can not handle them as mounts or
bind mounts, unless you do this explicaitly in /etc/fstab or
/etc/fstab.d/$USER


Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[L A Walsh]

Corinna Vinschen wrote:
> On Mar 11 15:57, L A Walsh wrote:
>   
>> 	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.
>>     
>
> As I wrote (multiple times now?), we can handle dir junctions as
> symlinks or as normal directories.  We can not handle them as mounts or
> bind mounts, unless you do this explicaitly in /etc/fstab or
> /etc/fstab.d/$USER
>   
To a user program, a mountvol looks like a normal directory.
When I talk about a 'bind' mount, I refer to the linux-facility
for mounting an arbitrary directory on a volume on another
directory on linux.  On windows, one uses JUNCTIONs to achive
a similar effect.  In both cases, they look like normal directories.


That said, why not make treating it as a normal
directory dependent on "winsoftlinks:mount" in
the 'CYGWIN' var, with 'winsoftlinks:symlink being
the default (doesn't have to be present in CYGWIN var
to get current behavior). Note, I'm using 'softlink'
as MS uses when talking about JUNCTIONS -- with the new
Vista feature being SYMLINKs.

Thinking about it, when one wants to do backups, the
env-"switch" gives the option of which behavior one gets
(if that's possible/not too hard) -- either the 'normal dir'
look or the current, symlink look.




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

Re: Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[cyg Simple]

On 3/11/2017 7:03 PM, L A Walsh wrote:
> cyg Simple wrote:
>> On 3/10/2017 4:01 PM, L A Walsh wrote:
>>  
>>>    I want to be able to mount other areas of other file
>>> systems onto directories.  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"?
>>>
>>>     
>>
>> Linda, I'm not trying to reject what you're saying which I find very
>> sound.  But for this scenario why not just use an entry in /etc/fstab
>> similar to the below example?
>>   
> ----
>    I want my filesystem views between Windows and Cygwin to be
> the same, as they, for the most part, are as I have:
> 
>> mount -p
> Prefix              Type         Flags
> /                   user         binmode
> 

Just as I do.

> So in cygwin /m/foo == M:\foo in windows and
> //server/pathname in cygwin == \\server\pathname in Windows.
> 
> I use cygwin to manage my windows installation to some degree.
> 

Sure, why not.  What you're trying to do though can be done with manual
entries in the /etc/fstab.  You're issue as I've heard it is with
setup-*.exe and how it manages those junctions as symlinks and somehow
manages to mess up the junction because it replaces it with a Cygwin
style symlink.  Setup-*.exe is a Windows application but uses some of
Cygwin functions to help it and executes the postinstall files using a
Cygwin shell.

-- 
cyg Simple

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