Symbolic links on NTFS with real symbolic links

[Neil Mowbray]

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?

Also rm <link> removes the target of the symbolic link not the link file.
Is this what you want?

Regards, Neil


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Larry Hall (Cygwin)]

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.

> 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.
You may want to see if you can reproduce the behavior on 1.7 before
reporting it though, since 1.5 isn't going to be updated anymore.  FWIW, if
you don't care for the Windows shortcut-style symlinks, my guess is you'll
be less enthused with the "new" special text file that 1.7 uses.  Them's the
breaks. ;-)

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

[Corinna Vinschen-2]

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

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

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple