Mail Archives: cygwin-developers/2000/06/08/18:26:03
> 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.
- Raw text -