This is the mail archive of the
mailing list for the Cygwin project.
Re: Symbolic links on NTFS with real symbolic links
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 29 Oct 2009 10:17:16 +0100
- Subject: Re: Symbolic links on NTFS with real symbolic links
- References: <003501ca5858$70595730$510c0590$@Mowbray@calgacus.com> <4AE938D5.firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
On Oct 29 02:40, Larry Hall (Cygwin) wrote:
> On 10/29/2009 01:26 AM, Neil Mowbray wrote:
> >Dear Folks,
> >On NTFS systems that support real symbolic links (eg those with Vista)
> >the comand ln -s does *not* create a native symbolic link merely an old
> >style shortcut.
> >Will ln -s be chansed to support native symbolic links?
> No, not until, at least, native symbolic links don't require
> elevated privileges to
And even then, no. We need symlinks which support POSIX style content.
Native Windows symlinks are just reparse points with a special symlink
tag. The path stored in them is expected to be a Win32 path.
Actually the target path is stored twice. The "SubstituteName" is a
native NT path, the "PrintName" is just some UI string, in theory. If
you use CMD's mklink command, the "PrintName" is filled with the Win32
This looks like a neat way to use a symlink for POSIX paths. Since
"SubstituteName" already contains the native NT path, just store the
POSIX path in "PrintName". Unfortunately this doesn't work. For some
reason the Win32 API requires the "PrintName" to contain the Win32 path,
otherwise you'll get "The system cannot find the file specified." error
messages. And it also doesn't work the other way around. If the
"PrintName" contains a valid Win32 path, and "SubstituteName" contains
the POSIX path, you *still* get the "The system cannot find..." error.
So there are two problems:
- Only users with administrator permissions can create native symlinks.
- Due to the way they are used in the Win32 API, there's no way to
use them with POSIX paths *and* Win32 paths for interoperability.
So why bother?
> >Also rm<link> removes the target of the symbolic link not the link file.
> >Is this what you want?
> Please provide a simple test case with the associated information requested
> by <http://cygwin.com/problems.html>. I cannot reproduce this behavior. Of
> course, I'm using Cygwin 1.7 <http://cygwin.com/#beta-test> on Windows 7.
Yes, indeed. Cygwin 1.5 doesn't recognize native symlinks and
consequentially the unlink() function didn't use the
FILE_OPEN_REPARSE_POINT flag to open the file for deletion.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple