This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Symbolic links on NTFS with real symbolic links

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

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 <>.  I cannot reproduce this behavior.  Of
> course, I'm using Cygwin 1.7 <> 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
Red Hat

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]