This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: [RFD]: Using a new feature of Win2K for symlinks


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]