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

[Corinna Vinschen <corinna at vinschen dot de>]

Hi,

another point of discussion:

The current implementation of symlinks is not transparent
to native Windows applications as you all know.

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.

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

	Windows shall open a file. It notices the reparse
	point, loads the tag and identifies the driver which
	has to care for that reparse information to do any
	appropriate action. The driver gets the reparse point
	content and has to do the work.

To implement your own drive is somewhat complicated and
requires registration of your vendor specific tag at Microsoft
and a special enhancement to the W2K DDK.

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

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

The last method is completely transparent to any windows
application and over shares! All native windows applications
only see a directory. This is valid for non-W2K machines in
the network, too. The translation to the target directory
is done by NTFS5. Oh, BTW, I forgot to mention, that the
symlink itself _must_ be a directory.

I have a patch to cygwin which uses that feature to
do the following:

	A Cygwin application wants to create a symlink.
	The symlink function in the Cygwin DLL looks
	for the target of the symlink and recognizes
	a directory. Now it checks if the filesytem which
	shall contain the symlink is able to manage
	reparse points (NTFS5). If so, it tries to create
	the symlink as reparse point instead of as  If it
	fails, it falls back to the `Cygwin standard' to
	create the symlink as regular file with system bit
	set.

The second half of the patch is to allow Cygwin to recognize
that `reparse mount point symbolic links' (Agh) so that cygwin
applications _see_ that it's a symlink and not the original
directory.

Disadvantage:

	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 ?!?

Advantage:

	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.

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!

Corinna