NTFS Symlinks (reparse point) redux

Linda Walsh cygwin@tlinx.org
Thu Nov 5 22:55:00 GMT 2009


Sorry to bring up and older topic, but I'm only beginning to explore Vista
and run into some of its cra^h^h^hnew features.

Corinna Vinschen wrote:

> On Oct 29 02:40, Larry Hall (Cygwin) wrote:
>> On 10/29/2009 01:26 AM, Neil Mowbray wrote:
>>> On NTFS systems that support real symbolic links (eg those with Vista)
>>> 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.
-----
   They don't have to..."sorta": Under the User-rights assignment plugin,
where you assign what users/groups have what priviledges, you can 'allow'
USERS, or ALL ATHENTICATED USERS to have the priviledge.  Then it doesn't
require them to be an Administrator to use. They might still get a "press
ok to continue" prompt if they have UAC turned on (though I'm not sure how
many end-users would want to leave that on by default), but if you have UAC
turned off, then even if you run as a regular user (in group Users), you'd
still have that privilege.     

> And even then, no.  We need symlinks which support POSIX style content.
---
   Why?  Can't cygwin convert it? Not that I'm necessarily pushing for this
-- they are different from the normal cygwin conception of symlinks.

> So there are two problems: - Only users with administrator permissions
> can create native symlinks.

---
   Can be worked around.

> - 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?
---
   Well -- because it would be _nice_ to have symlinks created in cygwin,
also be recognized and usable when one looks at the same links in explorer.


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

>> I cannot reproduce this behavior 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.

    Does this mean utils like 'file' or 'tar' or 'cp' will correctly detect
it as a symlink as well?



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



More information about the Cygwin mailing list