Message-Id: <200006082225.SAA29829@delorie.com>
Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
From: "Parker, Ron" <rdparker AT butlermfg DOT com>
To: cygdev <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: RE: [RFD]: Using a new feature of Win2K for symlinks
Date: Thu, 8 Jun 2000 17:24:11 -0500 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1252"

> Windows 2000 has a new feature which is called `reparse points'.
> A reparse point is a special block of information, saved
> like eg. security descriptors in a special stream of NTFS files.

I have been interested in this feature since I first heard about it long
before the first beta was released.  However as I have occassionally
investigated it since then, I have been disappointed.

> The reparse point itself has a tag which identifies a driver,
> which can be installed by applications to get the following
> behaviour:

...

> But fortunately Microsoft has (besides others) two predefined
> tags with the promising names
> 
> 	IO_REPARSE_TAG_SYMBOLIC_LINK
> 	IO_REPARSE_TAG_MOUNT_POINT
> 
> I have investigated further and I got the following results:
> 
> - I'm able to read and write reparse points of both types.
> 
> - The IO_REPARSE_TAG_SYMBOLIC_LINK is nice but completely useless
>   at the moment or on a base W2K system (I don't know exactly).

IIRC this was a feature that didn't quite make it.  It was only partially
implemented in even the RC's for 2000 and I have a vague recollection of the
mention of third-party support.  In my mind this was an obcure reference to
waiting on Interix to do something.

> - The IO_REPARSE_TAG_MOUNT_POINT is used to mount complete
>   partitions from logical drive manager and, surprise, surprise,
>   you can use it to create symbolic links to directories.

FWIW, this only works on local drive resources, but not to network
directories.  That is a function of DFS.

...

> 	Reparse point symlinks are always absolute windows
> 	paths. Relative paths are impossible. So that patch
> 	always changes the incoming path to an absolute
> 	windows path. Maybe, this will break some apps ?!?

This is a problem and one of the main reasons I had not submitted a patch
for using reparse points.  

Last night I was looking into a cygwin bug with relative symlinks and found
some old email in the archive that referred to problems with absolute paths
in the symlinks prior to when cygwin used relative paths.  I know there were
more than this and these aren't very good examples.  But at least they
provide a small sample,
http://sourceware.cygnus.com/ml/cygwin/1998-11/msg00078.html, and
http://sourceware.cygnus.com/ml/cygwin/1998-12/msg00102.html

> 	Symlinks to directories are now transparent
> 	to Windows apps at least on NTFS5 and with W2K
> 	I think that is a good start. And hopefully 
> 	Microsoft will implement symlinks to regular
> 	files with that method later, too.

The problem is that when file systems with reparse points are shared across
a network other machines do not see them as a symlink.  They see them as a
regular file.  This is especially true for Win9x machines.  

I thought I recalled Chris making a similar objection when someone suggested
that NTEA's or NT Security information be used to store symlink information.
However searching the archive I found a thread about using NTSEC on SAMBA
drives for symlink information,
http://sourceware.cygnus.com/ml/cygwin-developers/2000-03/threads.html#00059
.  Perhaps it was one of the other candidate-for-symlink mechanisms that I
am remembering.

> Ah, I remember the reason for that mail:
> 
> Asking for your opinion!
> 
> Shall we:
> 
> - Forget that patch completely?
> - Create some new option for the user?
> - Well, Wow! I always have waited for that! Go ahead!

How about using IO_REPARSE_TAG_MOUNT_POINT tags to implement mount
functionality for local resources on Windows 2000.  I know its not as sexy
as OS support for real symlinks, but it is a start.