Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Message-ID: <394007B4.FADA8798@vinschen.de> Date: Thu, 08 Jun 2000 22:53:08 +0200 From: Corinna Vinschen Reply-To: cygdev Organization: Cygnus Solutions, a Red Hat company X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: de, en MIME-Version: 1.0 To: cygdev Subject: [RFD]: Using a new feature of Win2K for symlinks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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