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]

NTFS Symlinks (reparse point) redux

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
  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
<> 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:
Unsubscribe info:

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