Mail Archives: cygwin-developers/2000/06/08/16:53:30
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
- Raw text -