Re: Request for Junctions be treated consistently

[Linda Walsh <cygwin at tlinx dot org>]

> > Corinna Vinschen wrote:
> > > No, it's not.  There's a major difference between mount points and
> > > symlinks, which is, mount points are handled inside the kernel, while
> > > symlinks are filesystem objects.  Reparse points are very certainly
> > > filesystem objects.  And bind mounts in Cygwin are handled in the
> > > "kernel" as well.  We can't add reparse points to the mount table
> > > on the fly.
> > ---
> > Windows Internals V5, p965
> > [snip]
>
> I know how reparse points work, but thanks all the same.
---
	Then you know that they used to be regularly referred to
as 'mount points'.


> > Theoretically, there should be a cental resource that would enable you to know
> > all the reparse points that are associated with mountpoints that wouldn't have
> > to be added "on the fly", but could be added to /etc/fstab on cygwin-initialization.
>
> I'm not sure how we came to discuss adding Windows mount points to
> /etc/fstab,
----
	It was in response to you saying that you can't add reparse points
to the mount table "on the fly" with the user space mapping of mounts being
held in fstab (usually).  But if that's not what you want, then I'm not sure
why you mentioned it.


> > But the one created with 'linkd' is called a Mount Point.
>
> So because one Microsoft tool calls directory junctions "mount points",
---
And the most authoritative NT-Internals book -- also calls them
mount points.  The original literature referred to them as mount points
frequently -- it took finding a relatively 'unchanged tool', from that
era (fsutil) to find the original description.


> they are mount points from a POSIX POV?
----
	If MS was POSIX, then why would someone need cygwin?
That seems like a straw-man argument.  The point was that they were
designed and documented to act like mount points.



> Again, we can't make the directory junctions POSIX mount points.  The
> mount table is in memory and has a fixed, limited size.  The only choice
> you have is to handle a directory junction as symlink or as plain
> directory.  The latter is wrong since it's not a plain directory. 
---
Neither is it a plain symlink -- functionality is lost by treating
it that way, and there is no workaround (that I know of).
I don't see what the big problem is -- you allow the possibility
with mountvol of duplicate content.  Why not draw the line
at what MS calls mount points and what they call symlinks?

>  It's
> just a file system object pointing to the real directory.  If you
> handle it as directory, find and other recursive tools would enumerate
> the directory twice, once via the real directory entry, once via the
> reparse point. And there would be no way at all from a POSIX POV to
> distinguish the two.
---
An administrator using these options would take the same risk
they take on linux -- If they use tar or find where content is loaded
in multiple places, it will be enumerated in multiple places.
It takes administrative access to create them.  An unprivileged
user will get "access denied" or "insufficient privilege".

That provides for the feature, but restricts it to those who
can do full backups.

The alternative is broken or missing functionality.

It's not like I'm asking you to implement something new -- just
to treat 'JUNCTION' mountpoints equally whether they point
to a volume root or a volume-root+offset(path).

Linux went out of its way to provide a bunch of these features even
though they require some common sense when using them.

I think it unlikely that many people will use Junctions -- BECAUSE
they aren't as versatile as symlinks for most purposes.  But in
cases where you don't want cp-a or cp-r or a tar-xaf to create a
new copy of something -- when, currently, only 1 copy exists,
is *worse* than it creating full, redundant copies during
archive creation.

Why worse?: on extraction, the 'symlink' is overwritten
and only the new files in the tar are extracted into the new
directory.  All previous content is 'lost' (still at the original
location), but if you have 'terminfo' in /usr/share/terminfo, where,
"/usr/share",  is, by design, supposed to contain architecture-independent,
sharable content, then when you untar a manpage for 'anything',
the 'share' link is overwritten and you find your terminal functions
no longer work.

Even with the downside of creating or enumerating multiple copies of the
same source, it's still less drastic than the effects of disabling
local mounts.

That's why I asked for the functionality to be rolled-back to where
it still was seen as a directory -- consistent with 'mountvol' behavior.

It allows more 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