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