This is the mail archive of the
mailing list for the Cygwin project.
Re: Request for Junctions be treated consistently
- From: Linda Walsh <cygwin at tlinx dot org>
- To: cygwin at cygwin dot com
- Date: Wed, 09 Apr 2014 13:08:32 -0700
- Subject: Re: Request for Junctions be treated consistently
- Authentication-results: sourceware.org; auth=none
- References: <5336C0DF dot 5080102 at tlinx dot org> <5336C23B dot 2070309 at tlinx dot org> <20140331102745 dot GD23383 at calimero dot vinschen dot de> <533AEBD6 dot 3040209 at tlinx dot org> <20140402084026 dot GM2508 at calimero dot vinschen dot de> <533FE56D dot 5010809 at tlinx dot org> <20140407092342 dot GF2061 at calimero dot vinschen dot de> <1675705369 dot 20140407220427 at yandex dot ru> <20140408083955 dot GA28755 at calimero dot vinschen dot de> <53453800 dot 9010603 at tlinx dot org> <20140409172654 dot GB22721 at calimero dot vinschen dot de>
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
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
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?
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
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
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple